DEV Community

Cover image for Vertical Slice Architecture: organizzare per feature, non per layer
Dev-Iadicola
Dev-Iadicola

Posted on • Originally published at iadicola.it

Vertical Slice Architecture: organizzare per feature, non per layer

Il problema dell'organizzazione per layer

In un'architettura layered classica, i file sono organizzati per tipo: Controllers/, Services/, Models/, Repositories/. Per aggiungere una feature "esporta ordini in PDF", devi creare file in 4 directory diverse: un controller, un service, un repository method, un template. Per capire come funziona la feature, devi saltare tra 4 cartelle. Per eliminarla, devi trovare e rimuovere codice in 4 posti.

La Vertical Slice Architecture, popolarizzata da Jimmy Bogard, inverte l'organizzazione: invece di raggruppare per tipo tecnico (tutti i controller insieme), raggruppa per feature (tutto cio che serve per "esporta ordini in PDF" insieme). Ogni slice e una fetta verticale che attraversa tutti i layer.

Struttura: ogni feature e autocontenuta

Invece di:

  • Controllers/OrderController.php (contiene export + list + create + update + ...)
  • Services/OrderService.php (contiene logica di export + list + create + ...)
  • Repositories/OrderRepository.php (contiene query di export + list + ...)

Hai:

  • Features/Orders/ExportPdf/ExportOrdersPdfAction.php
  • Features/Orders/ExportPdf/ExportOrdersPdfQuery.php
  • Features/Orders/ExportPdf/ExportOrdersPdfTemplate.php
  • Features/Orders/ListOrders/ListOrdersAction.php
  • Features/Orders/ListOrders/ListOrdersQuery.php

Ogni feature e una directory con tutto il necessario. Aprire la directory ti mostra l'intera feature. Eliminare la directory elimina la feature completamente.

Vantaggi concreti

  • Coesione: tutto cio che cambia insieme vive insieme. Modificare una feature tocca file nella stessa directory.
  • Navigabilita: "come funziona l'export PDF?" — apri Features/Orders/ExportPdf/. Tutto li.
  • Indipendenza: ogni slice può usare pattern diversi. Una feature semplice usa query dirette. Una complessa usa CQRS. Non serve uniformita forzata.
  • Merge conflict ridotti: due sviluppatori che lavorano su feature diverse non toccano gli stessi file.
  • Eliminabilita: rimuovere una feature e cancellare una directory. Zero rischio di lasciare codice orfano.

Vertical Slice vs Layered

  • Layered: i file sono raggruppati per ruolo tecnico. Un cambio di feature attraversa molte directory.
  • Vertical Slice: i file sono raggruppati per feature. Un cambio di feature e localizzato in una directory.

Non si escludono: dentro ogni slice puoi avere layer interni (action, query, template). La differenza e che i layer sono locali alla feature, non globali all'applicazione.

Esempio: un blog con Vertical Slice

  • Features/Articles/ListPublished/ — action + query + view per la lista articoli
  • Features/Articles/ShowBySlug/ — action + query + view per il singolo articolo
  • Features/Articles/CreateArticle/ — action + command + validation + form view
  • Features/Contact/SendMessage/ — action + command + email service + form view

Quando usare Vertical Slice

  • Usa Vertical Slice quando l'applicazione ha molte feature indipendenti
  • Usa Vertical Slice quando il team lavora su feature diverse in parallelo
  • Usa Vertical Slice quando i controller e i service crescono troppo e diventano "catch-all"
  • Non usare Vertical Slice per applicazioni molto piccole dove la struttura layered e sufficiente
  • Non usare Vertical Slice se le feature condividono molta logica: la duplicazione tra slice diventa un problema

La Vertical Slice Architecture e il pattern della localita: tutto cio che serve per una feature vive nello stesso posto. Non e un'alternativa radicale alla Layered Architecture — e un'evoluzione che privilegia la coesione funzionale su quella tecnica. Quando le feature crescono e i layer diventano contenitori generici, le slice verticali riportano ordine.


👉 Leggi l'articolo completo su iadicola.it

Top comments (0)