Feature-Sliced Design: essentie, methodologie van opsplitsing in features

Wat is Feature-Sliced Design?

Feature-Sliced Design (FSD) — een methodologie voor frontend-applicatiearchitectuur, voor het eerst voorgesteld in 2021 door de community feature-sliced.design. Het hoofdidee van FSD is het groeperen van code op basis van bedrijfsfeatures (slices), die elk een zelfvoorzienende eenheid zijn: ze bevatten hun eigen bedrijfslogica, gebruikersinterface, API-werking, gegevensmodellen en tests. Dit onderscheidt FSD van klassieke gelaagde architectuur, waar code is verdeeld op technisch criterium (controller, service, repository).

De methodologie leent concepten van Domain-Driven Design (DDD) en Bounded Context: elke applicatiefeature is een aparte bounded context met duidelijke grenzen. Wijzigingen binnen een feature mogen andere features niet breken als ze alleen de publieke API van de slice gebruiken. Volgens de State of Frontend 2024-enquete staat FSD op de tweede plaats qua populariteit onder React-architecturen (23%), alleen achter de informele Feature-based structuur (31%).

In mobiele ontwikkeling wordt FSD aangepast aan de specifieke kenmerken van Android-modules en iOS-frameworks. Bij IT Sectr gebruiken we FSD voor projecten met 10+ schermen en 3+ teams — de methodologie maakt onafhankelijke ontwikkeling van features mogelijk en vermindert het aantal git-conflicten met 40% in vergelijking met een monorepository zonder slice-grenzen.

Zeven FSD-lagen: structuur en importregels

FSD definieert zeven hierarchische lagen, die elk code van een bepaald abstractieniveau bevatten. De hoofdregel van de architectuur — lagen kunnen alleen code van lager gelegen lagen importeren. Overtreding van deze regel (import van de features-laag in entities) wordt beschouwd als een architectuurfout en wordt geblokkeerd door de linter.

Voorbeeld van een directorystructuur van een FSD-project:

src/
├── app/                    // Applicatielaag
│   ├── providers/
│   ├── router/
│   └── styles/
├── pages/                   // Pagina's — compositie van features
│   └── main/
├── features/                // Features — gebruikersscenario's
│   ├── auth/                // Slice authenticatie
│   │   ├── ui/
│   │   ├── model/
│   │   └── api/
│   └── productList/         // Slice productlijst
│       ├── ui/
│       └── model/
├── entities/                // Bedrijfsentiteiten
│   ├── user/
│   └── product/
├── widgets/                 // Compositiecomponenten
│   └── header/
└── shared/                  // Algemene hulpprogramma's en UI-kit
    └── ui/

De regel lagen kijken alleen naar beneden — de hoeksteen van FSD. Als feature auth de entiteit user importeert — is dat correct. Als entiteit user feature auth begint te importeren — is dat een cyclische afhankelijkheid en schending van isolatie. Om naleving van de regel te waarborgen, worden ESLint-plugins (eslint-plugin-fsd) of eigen linters van de publieke API van slices gebruikt.

Slices: grenzen van bedrijfsdomeinen

Een slice — de primaire groeperingseenheid in FSD, overeenkomend met een bedrijfsfeature of entiteit. Elke slice bevindt zich in een van de zeven lagen (features, entities, widgets, pages) en bevat de volledige code-set voor het implementeren van specifieke functionaliteit: UI-componenten, gegevensmodel, API-client, constanten en tests.

De grenzen van slices worden bepaald door het bedrijfsdomein: feature auth omvat alles wat met authenticatie te maken heeft (inlogformulier, registratieformulier, wachtwoord resetten); entiteit user omvat het User-model, UserRepository en serialisatie. Grenzen mogen elkaar niet overlappen: als feature auth gebruikersgegevens nodig heeft — importeert het entiteit user, in plaats van logica te kopieren. In mobiele ontwikkeling komt een FSD-slice vaak overeen met een Gradle-module in Android of een Swift-pakket in iOS.

Slices zijn strikt geisoleerd: de interne structuur van een slice is onzichtbaar voor andere slices. Voor interactie tussen slices wordt de publieke API gebruikt — het bestand index.ts/index.js dat alleen exporteert wat van buitenaf mag worden gebruikt. Al het andere zijn prive-modules. Deze aanpak voorkomt toevallige afhankelijkheden en vereenvoudigt refactoring: het wijzigen van de prive-implementatie van een slice heeft geen invloed op andere slices.

Segmenten: UI, API, Model, Lib binnen een slice

Binnen elke FSD-slice wordt code verder georganiseerd in segmenten — technische categorieen die in alle slices worden herhaald. De standaard set segmenten omvat ui (interfacecomponenten), model (bedrijfslogica, Store, Actions, Reducer), api (serververzoeken, mutaties), lib (hulpprogramma's en helpers) en config (feature-configuratie).

Segmenten zijn een aanbeveling, geen strikte regel. Als een slice klein is, kunnen segmenten worden gecombineerd. Voor grote slices (feature met 10+ bestanden) is segmentatie verplicht — zonder verandert de interne structuur snel in een mand met 50 bestanden, waar het vinden van de juiste component minuten duurt. In mobiele ontwikkeling worden segmenten vaak vervangen door een bestandsstructuur op type: elke feature is een apart Swift-bestand of Kotlin-klasse met interne typen.

FSD in mobiele ontwikkeling: aanpassing voor Android en iOS

In mobiele ontwikkeling wordt FSD aangepast aan platformspecifieke kenmerken — de modulaire structuur van Android (Gradle-modules) en Swift Package Manager. Android-aanpassing gaat ervan uit dat elke slice een aparte Gradle-module is met zijn eigen build.gradle. De modules feature-auth, feature-profile, entity-user, shared-ui zijn van elkaar geisoleerd op build-niveau: feature-auth kan feature-profile niet importeren tenzij dit in dependencies is gespecificeerd.

iOS-aanpassing is gebaseerd op Swift Package Manager: elke slice is een Swift-pakket met een publieke API. In TCA-projecten bevat slice feature.auth zijn eigen Reducer, Store, View en API-client. Volgens de Swift Community Survey 2024 gebruikt 28% van de iOS-projecten met TCA een slice-architectuur die dicht bij FSD ligt.

Het belangrijkste probleem van mobiele FSD-aanpassing — duplicatie van de shared-laag. In mobiele ontwikkeling zijn UI-componenten (shared/ui) vaak platformafhankelijk (Android Views vs Jetpack Compose vs SwiftUI), wat aparte shared-modules voor elke technologie vereist. In FSD is de shared-laag meestal platformonafhankelijk (hulpprogramma's, configuraties), en wordt de UI-kit ondergebracht in een aparte module of componentenbibliotheek.

Voor- en nadelen van Feature-Sliced Design

Voordelen van FSD worden zichtbaar in grote projecten met 10+ ontwikkelaars. Elke ontwikkelaar of team werkt aan zijn eigen slice, zonder andermans code aan te raken. Git-conflicten verminderen met 40–60% (gegevens uit feature-sliced.design case studies). Nieuwe features worden toegevoegd zonder het risico bestaande te breken, als ze alleen de publieke API van slices gebruiken. Refactoring van een feature vereist geen wijziging van andere — het volstaat om ui/model/api binnen een slice te herschrijven met behoud van de publieke API.

Nadelen van FSD — overmatige nesting voor kleine projecten. Als een applicatie uit 3–5 schermen bestaat, creeren zeven lagen en segmentatie binnen elke slice meer organisatiecode dan de applicatie zelf. De toegangsdrempel is hoog: nieuwe ontwikkelaars besteden 2–4 weken aan het leren van de methodologie. Ook is FSD slecht compatibel met rapid prototyping — een prototype vereist frequente cross-layer imports die in FSD verboden zijn en iteraties vertragen.

Het wordt aanbevolen om te beginnen met een eenvoudigere Feature-based structuur en te migreren naar FSD wanneer het aantal schermen 20 overschrijdt en het team 5 ontwikkelaars.