Feature Architecture in React: Vertical Slices e Ownership

L’errore più comune nelle codebase React che crescono è l’organizzazione per “tipo di file”. Mettere tutti i componenti in components/, tutti gli hook in hooks/ e tutti i tipi in types/ è l’equivalente architetturale di lanciare vestiti alla rinfusa in un armadio sperando di ritrovare i calzini.

Il Senior Architect organizza per dominio, non per tecnologia.

In questo approfondimento esploreremo come passare da una struttura basata sui layer a una basata sulle Feature, utilizzando il concetto di Vertical Slicing per garantire scalabilità e ownership.

Il Problema del Layer-First Design

L’approccio orizzontale (per layer) crea un accoppiamento implicito e devastante. Per modificare una singola funzionalità (es. “Gestione Carrello”), uno sviluppatore deve navigare attraverso dieci cartelle diverse sparse per l’intera codebase.

Perché il Layer-First fallisce su scala:

1. Cognitive Load: Devi tenere a mente l’intera struttura del progetto per fare una piccola modifica.
2. Fragilità delle Dipendenze: È facile importare accidentalmente qualcosa che non dovrebbe essere condiviso.
3. Ownership complessa: Chi è il proprietario della cartella utils/ quando contiene logica di dieci feature diverse?

Vertical Slicing: Isolare il Dominio

Il Vertical Slicing propone di tagliare l’applicazione in “fette” verticali, dove ogni fetta rappresenta una feature completa e autonoma.

Una Feature deve contenere tutto ciò di cui ha bisogno per esistere: UI, Business Logic, API types e State Management.

Struttura di una Feature Scalabile

Immaginiamo una feature ProductSearch. Invece di sparpagliarla, la confiniamo in un modulo atomico:

src/features/product-search/
├── api/             # Sincronizzazione dati specifica
├── components/      # UI interna non condivisa
├── hooks/           # Logica di dominio (es. *useSearchSorting*)
├── types/           # Contratti della *feature*
├── index.ts         # Public API (il contratto esterno)

Boundaries e Public API

Il segreto di un’architettura feature-first non è solo dividere in cartelle, ma applicare Strict Boundaries.

Il file index.ts come Guardiano

Ogni feature deve esporre solo ciò che è strettamente necessario all’esterno attraverso un file index.ts. Tutto il resto è considerato privato.

• Se un componente in src/features/cart ha bisogno di qualcosa da src/features/product-search, può importare solo dalla Public API esposta nell’index.
• Questo previene il “Deep Nesting” di importazioni che rende il refactoring impossibile.

Ownership Tecnica e Team Scalability

Quando la struttura riflette il dominio, l’architettura diventa un alleato dell’organizzazione e della governance.

Allineamento tra Squad e Codebase

In un’organizzazione scalabile, i vari team (squad) possono avere la Total Ownership su specifiche cartelle features/.

• Autonomia: Un team può rifattorizzare la logica interna di una feature senza timore di rompere parti non correlate del sistema. È qui che entra in gioco una solida ownership dello stato per garantire che i cambiamenti non abbiano side-effect globali.
• Velocity: Minori merge conflict poiché il raggio d’azione di ogni sviluppatore è limitato alla fetta verticale su cui sta lavorando.

Matrice Decisionale: Layer vs Feature

Conclusione: Architettura come Espressione del Prodotto

Strutturare il codice React intorno alle feature significa smettere di pensare come uno “sviluppatore di librerie” e iniziare a pensare come un Product Engineer.

Il passaggio al Vertical Slicing non è solo una scelta di cartelle; è una decisione strategica per contenere l’entropia della complessità e permettere al sistema di evolvere alla stessa velocità del business, adottando strategie di rendering evolute dove necessario.

Ricorda: i layer sono dettagli tecnici. Le feature sono il valore del prodotto.

Condividi su LinkedIn