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 ciò che serve per "esporta ordini in PDF" insieme). Ogni slice è una fetta verticale che attraversa tutti i layer.

Struttura: ogni feature è 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 è 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 ciò che cambia insieme vive insieme. Modificare una feature tocca file nella stessa directory.
• Navigabilità: "come funziona l'export PDF?" — apri Features/Orders/ExportPdf/. Tutto lì.
• Indipendenza: ogni slice può usare pattern diversi. Una feature semplice usa query dirette. Una complessa usa CQRS. Non serve uniformità forzata.
• Merge conflict ridotti: due sviluppatori che lavorano su feature diverse non toccano gli stessi file.
• Eliminabilità: rimuovere una feature è 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 è localizzato in una directory.

Non si escludono: dentro ogni slice puoi avere layer interni (action, query, template). La differenza è 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 è sufficiente
• Non usare Vertical Slice se le feature condividono molta logica: la duplicazione tra slice diventa un problema

La Vertical Slice Architecture è il pattern della località: tutto ciò che serve per una feature vive nello stesso posto. Non è un'alternativa radicale alla Layered Architecture — è 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.