Feature-Sliced Design: essenza e metodologia di suddivisione per feature

Cos'è Feature-Sliced Design?

Feature-Sliced Design (FSD) è una metodologia di architettura per applicazioni frontend proposta per la prima volta nel 2021 dalla comunità feature-sliced.design. L'idea centrale di FSD è raggruppare il codice per funzionalità di business (slice), ciascuna delle quali è un'unità autosufficiente: contiene la propria logica di business, interfaccia utente, interazione API, modelli dati e test. Questo distingue FSD dall'architettura classica a livelli dove il codice è suddiviso per criteri tecnici (controller, service, repository).

La metodologia prende in prestito concetti dal Domain-Driven Design (DDD) e dal Bounded Context: ogni feature dell'applicazione è un bounded context separato con confini chiari. Le modifiche all'interno di una feature non devono rompere altre feature se queste utilizzano solo l'API pubblica dello slice. Secondo il sondaggio State of Frontend 2024, FSD occupa il secondo posto in popolarità tra le architetture React (23%), seconda solo alla struttura informale Feature-based (31%).

Nello sviluppo mobile, FSD si adatta alle specificità dei moduli Android e dei framework iOS. In IT Sectr, utilizziamo FSD per progetti con 10+ schermate e 3+ team — la metodologia consente di sviluppare feature in modo indipendente e riduce i conflitti git del 40% rispetto a un monorepo senza confini di slice.

Sette livelli di FSD: struttura e regole di importazione

FSD definisce sette livelli gerarchici, ciascuno contenente codice di un certo livello di astrazione. La regola architetturale principale è che i livelli possono importare solo codice da livelli inferiori. Violare questa regola (importare il livello features in entities) è considerato un errore architetturale e viene bloccato da un linter.

Esempio di struttura di directory di un progetto FSD:

src/
├── app/                    // Livello applicazione
│   ├── providers/
│   ├── router/
│   └── styles/
├── pages/                   // Pagine — composizione di feature
│   └── main/
├── features/                // Feature — scenari utente
│   ├── auth/                // Slice «Autenticazione»
│   │   ├── ui/
│   │   ├── model/
│   │   └── api/
│   └── productList/         // Slice «Elenco prodotti»
│       ├── ui/
│       └── model/
├── entities/                // Entità di business
│   ├── user/
│   └── product/
├── widgets/                 // Componenti compositi
│   └── header/
└── shared/                  // Utilità condivise e UI-kit
    └── ui/

La regola «i livelli guardano solo verso il basso» è la pietra angolare di FSD. Se feature auth importa entity user — è corretto. Se entity user inizia a importare feature auth — è una dipendenza ciclica e una violazione dell'isolamento. Per garantire questa regola, vengono utilizzati plugin ESLint (eslint-plugin-fsd) o linter personalizzati dell'API pubblica degli slice.

Slice: confini dei domini di business

Slice — l'unità principale di raggruppamento in FSD, corrispondente a una feature o entità di business. Ogni slice risiede all'interno di uno dei sette livelli (features, entities, widgets, pages) e contiene un set completo di codice per implementare una funzionalità specifica: componenti UI, modello dati, client API, costanti e test.

I confini degli slice sono definiti dal dominio di business: feature auth include tutto ciò che riguarda l'autorizzazione (modulo di login, modulo di registrazione, reset password); entity user include il modello User, UserRepository e serializzazione. I confini non devono sovrapporsi: se feature auth necessita di dati utente — importa entity user invece di duplicare la logica. Nello sviluppo mobile, uno slice FSD spesso corrisponde a un modulo Gradle in Android o a un pacchetto Swift in iOS.

Gli slice sono strettamente isolati: la struttura interna di uno slice è invisibile agli altri slice. Per l'interazione tra slice viene utilizzata un'API pubblica — un file index.ts/index.js che esporta solo ciò che è consentito all'uso esterno. Tutto il resto sono moduli privati. Questo approccio previene dipendenze accidentali e semplifica il refactoring: modificare l'implementazione privata di uno slice non influisce sugli altri slice.

Segmenti: UI, API, Model, Lib all'interno di uno slice

All'interno di ogni slice FSD, il codice è ulteriormente organizzato per segmenti — categorie tecniche che si ripetono in tutti gli slice. Il set standard di segmenti include ui (componenti di interfaccia), model (logica di business, Store, Actions, Reducer), api (richieste al server, mutazioni), lib (utilità e helper) e config (configurazione della feature).

I segmenti sono una raccomandazione, non una regola rigida. Se uno slice è piccolo, i segmenti possono essere uniti. Per slice grandi (una feature con 10+ file), la segmentazione è obbligatoria — senza di essa, la struttura interna si trasforma rapidamente in un «cestino» di 50 file dove trovare il componente necessario richiede minuti. Nello sviluppo mobile, i segmenti sono spesso sostituiti da una struttura di file per tipo: ogni feature è un file Swift separato o una classe Kotlin con tipi interni.

FSD nello sviluppo mobile: adattamento per Android e iOS

Nello sviluppo mobile, FSD si adatta alle caratteristiche specifiche della piattaforma — la struttura modulare di Android (moduli Gradle) e Swift Package Manager. Adattamento Android presuppone che ogni slice sia un modulo Gradle separato con il proprio build.gradle. I moduli feature-auth, feature-profile, entity-user, shared-ui sono isolati tra loro a livello di build: feature-auth non può importare feature-profile a meno che non sia specificato in dependencies.

Adattamento iOS è costruito su Swift Package Manager: ogni slice è un pacchetto Swift con un'API pubblica. Nei progetti TCA, lo slice feature.auth contiene il proprio Reducer, Store, View e client API. Secondo la Swift Community Survey 2024, il 28% dei progetti iOS con TCA utilizza un'architettura a slice vicina a FSD.

Il problema principale dell'adattamento mobile di FSD è la duplicazione del livello shared. Nello sviluppo mobile, i componenti UI (shared/ui) spesso dipendono dalla piattaforma (Android Views vs Jetpack Compose vs SwiftUI), richiedendo moduli shared separati per ogni tecnologia. In FSD, il livello shared è solitamente indipendente dalla piattaforma (utilità, configurazioni), mentre l'UI-kit viene spostato in un modulo separato o libreria di componenti.

Pro e contro di Feature-Sliced Design

Vantaggi di FSD diventano evidenti in progetti grandi con 10+ sviluppatori. Ogni sviluppatore o team lavora sul proprio slice senza toccare il codice altrui. I conflitti git si riducono del 40–60% (dati da case study di feature-sliced.design). Nuove feature vengono aggiunte senza il rischio di rompere quelle esistenti, purché utilizzino solo l'API pubblica degli slice. Refactorizzare una feature non richiede modifiche alle altre — basta riscrivere ui/model/api all'interno di uno slice mantenendo l'API pubblica.

Svantaggi di FSD — annidamento eccessivo per progetti piccoli. Se un'applicazione è composta da 3–5 schermate, sette livelli e segmentazione all'interno di ogni slice creano più codice organizzativo dell'applicazione stessa. La barriera d'ingresso è alta: i nuovi sviluppatori impiegano 2–4 settimane per apprendere la metodologia. Inoltre, FSD è poco compatibile con la prototipazione rapida — la prototipazione richiede frequenti importazioni tra livelli, che sono vietate in FSD e rallentano le iterazioni.

Si consiglia di iniziare con una struttura Feature-based più semplice e migrare a FSD quando il numero di schermate supera 20 e il team supera 5 sviluppatori.