Feature-Sliced Design: Wesen und Methodik der feature-basierten Aufteilung

Was ist Feature-Sliced Design?

Feature-Sliced Design (FSD) ist eine Frontend-Anwendungsarchitekturmethodik, die erstmals 2021 von der Community feature-sliced.design vorgeschlagen wurde. Die Kernidee von FSD ist die Gruppierung von Code nach Geschäftsfunktionen (Slices), wobei jede eine autarke Einheit ist: Sie enthält eigene Geschäftslogik, Benutzeroberfläche, API-Interaktion, Datenmodelle und Tests. Dies unterscheidet FSD von der klassischen Schichtenarchitektur, bei der Code nach technischen Kriterien (Controller, Service, Repository) aufgeteilt wird.

Die Methodik entlehnt Konzepte von Domain-Driven Design (DDD) und Bounded Context: Jede Anwendungsfunktion ist ein separater Bounded Context mit klaren Grenzen. Änderungen innerhalb einer Funktion sollten andere Funktionen nicht beeinträchtigen, solange sie nur die öffentliche API des Slices verwenden. Laut der State of Frontend 2024-Umfrage belegt FSD den zweiten Platz in der Beliebtheit unter React-Architekturen (23%), nur hinter der informellen Feature-basierten Struktur (31%).

In der mobilen Entwicklung passt sich FSD an die Besonderheiten von Android-Modulen und iOS-Frameworks an. Bei IT Sectr verwenden wir FSD für Projekte mit 10+ Bildschirmen und 3+ Teams — die Methodik ermöglicht unabhängige Feature-Entwicklung und reduziert Git-Konflikte um 40% im Vergleich zu einem Monorepo ohne Slice-Grenzen.

Sieben Schichten von FSD: Struktur und Importregeln

FSD definiert sieben hierarchische Schichten, die jeweils Code einer bestimmten Abstraktionsebene enthalten. Die wichtigste Architekturregel ist, dass Schichten nur Code aus darunterliegenden Schichten importieren können. Ein Verstoß gegen diese Regel (Import der Features-Schicht in Entities) gilt als Architekturfehler und wird von einem Linter blockiert.

Beispiel einer Verzeichnisstruktur eines FSD-Projekts:

src/
├── app/                    // Anwendungsschicht
│   ├── providers/
│   ├── router/
│   └── styles/
├── pages/                   // Seiten — Funktionskomposition
│   └── main/
├── features/                // Features — Benutzerszenarien
│   ├── auth/                // Slice «Authentifizierung»
│   │   ├── ui/
│   │   ├── model/
│   │   └── api/
│   └── productList/         // Slice «Produktliste»
│       ├── ui/
│       └── model/
├── entities/                // Geschäftsobjekte
│   ├── user/
│   └── product/
├── widgets/                 // Zusammengesetzte Komponenten
│   └── header/
└── shared/                  // Gemeinsame Utilities und UI-kit
    └── ui/

Die Regel «Schichten schauen nur nach unten» ist der Eckpfeiler von FSD. Wenn feature auth entity user importiert — ist das korrekt. Wenn entity user beginnt, feature auth zu importieren — ist das eine zyklische Abhängigkeit und ein Verstoß gegen die Isolation. Zur Durchsetzung dieser Regel werden ESLint-Plugins (eslint-plugin-fsd) oder benutzerdefinierte Linter der öffentlichen API von Slices verwendet.

Slices: Grenzen von Geschäftsdomänen

Slice — die Hauptgruppierungseinheit in FSD, die einer Geschäftsfunktion oder Entität entspricht. Jeder Slice befindet sich innerhalb einer der sieben Schichten (features, entities, widgets, pages) und enthält einen vollständigen Satz von Code zur Implementierung einer bestimmten Funktionalität: UI-Komponenten, Datenmodell, API-Client, Konstanten und Tests.

Slice-Grenzen werden durch die Geschäftsdomäne definiert: feature auth umfasst alles, was mit Autorisierung zu tun hat (Login-Formular, Registrierungsformular, Passwort-Reset); entity user umfasst das User-Modell, UserRepository und Serialisierung. Grenzen sollten sich nicht überschneiden: Wenn feature auth Benutzerdaten benötigt — importiert es entity user, anstatt die Logik zu duplizieren. In der mobilen Entwicklung entspricht ein FSD-Slice oft einem Gradle-Modul in Android oder einem Swift-Paket in iOS.

Slices sind streng isoliert: Die interne Struktur eines Slices ist für andere Slices unsichtbar. Für die Interaktion zwischen Slices wird eine öffentliche API verwendet — eine index.ts/index.js-Datei, die nur das exportiert, was zur externen Nutzung freigegeben ist. Alles andere sind private Module. Dieser Ansatz verhindert versehentliche Abhängigkeiten und vereinfacht die Refaktorisierung: Die Änderung der privaten Implementierung eines Slices beeinträchtigt andere Slices nicht.

Segmente: UI, API, Model, Lib innerhalb eines Slices

Innerhalb jedes FSD-Slices wird Code weiter nach Segmenten organisiert — technischen Kategorien, die sich in allen Slices wiederholen. Der Standardsatz von Segmenten umfasst ui (Schnittstellenkomponenten), model (Geschäftslogik, Store, Actions, Reducer), api (Serveranfragen, Mutationen), lib (Utilities und Helfer) und config (Feature-Konfiguration).

Segmente sind eine Empfehlung, keine strenge Regel. Wenn ein Slice klein ist, können Segmente zusammengelegt werden. Für große Slices (ein Feature mit 10+ Dateien) ist die Segmentierung obligatorisch — ohne sie verwandelt sich die interne Struktur schnell in einen «Korb» mit 50 Dateien, in dem das Auffinden der benötigten Komponente Minuten dauert. In der mobilen Entwicklung werden Segmente oft durch eine Dateistruktur nach Typ ersetzt: Jedes Feature ist eine separate Swift-Datei oder Kotlin-Klasse mit internen Typen.

FSD in der mobilen Entwicklung: Anpassung an Android und iOS

In der mobilen Entwicklung passt sich FSD an plattformspezifische Merkmale an — die modulare Struktur von Android (Gradle-Module) und Swift Package Manager. Android-Anpassung geht davon aus, dass jeder Slice ein separates Gradle-Modul mit eigenem build.gradle ist. Die Module feature-auth, feature-profile, entity-user, shared-ui sind auf Build-Ebene voneinander isoliert: feature-auth kann feature-profile nicht importieren, es sei denn, es ist in dependencies angegeben.

iOS-Anpassung basiert auf Swift Package Manager: Jeder Slice ist ein Swift-Paket mit einer öffentlichen API. In TCA-Projekten enthält der feature.auth-Slice seinen eigenen Reducer, Store, View und API-Client. Laut der Swift Community Survey 2024 verwenden 28% der iOS-Projekte mit TCA eine Slice-Architektur, die FSD nahekommt.

Das Hauptproblem der mobilen FSD-Anpassung ist die Duplizierung der shared-Schicht. In der mobilen Entwicklung hängen UI-Komponenten (shared/ui) oft von der Plattform ab (Android Views vs. Jetpack Compose vs. SwiftUI), was separate shared-Module für jede Technologie erfordert. In FSD ist die shared-Schicht in der Regel plattformunabhängig (Utilities, Konfigurationen), während das UI-kit in ein separates Modul oder eine Komponentenbibliothek ausgelagert wird.

Vor- und Nachteile von Feature-Sliced Design

Vorteile von FSD werden in großen Projekten mit 10+ Entwicklern deutlich. Jeder Entwickler oder jedes Team arbeitet am eigenen Slice, ohne den Code anderer zu berühren. Git-Konflikte werden um 40–60% reduziert (Daten aus Fallstudien von feature-sliced.design). Neue Funktionen werden ohne Risiko für bestehende Funktionen hinzugefügt, solange sie nur die öffentliche API von Slices verwenden. Die Refaktorisierung einer Funktion erfordert keine Änderungen an anderen — es genügt, ui/model/api innerhalb eines Slices umzuschreiben und dabei die öffentliche API beizubehalten.

Nachteile von FSD — übermäßige Verschachtelung für kleine Projekte. Wenn eine Anwendung aus 3–5 Bildschirmen besteht, erzeugen sieben Schichten und Segmentierung innerhalb jedes Slices mehr organisatorischen Code als die Anwendung selbst. Die Einstiegshürde ist hoch: Neue Entwickler benötigen 2–4 Wochen, um die Methodik zu erlernen. Außerdem ist FSD mit schnellem Prototyping schlecht kompatibel — Prototyping erfordert häufige schichtübergreifende Importe, die in FSD verboten sind und Iterationen verlangsamen.

Es wird empfohlen, mit einer einfacheren Feature-basierten Struktur zu beginnen und zu FSD zu migrieren, wenn die Anzahl der Bildschirme 20 übersteigt und das Team mehr als 5 Entwickler umfasst.