Feature-Sliced Design: istota, metodologia podziału na funkcjonalności

Czym jest Feature-Sliced Design?

Feature-Sliced Design (FSD) — metodologia architektury aplikacji frontendowych, po raz pierwszy zaproponowana w 2021 roku przez społeczność feature-sliced.design. Główną ideą FSD jest grupowanie kodu według funkcji biznesowych (slice'ów), z których każda jest samowystarczalną jednostką: zawiera własną logikę biznesową, interfejs użytkownika, obsługę API, modele danych i testy. To odróżnia FSD od klasycznej architektury warstwowej, gdzie kod jest podzielony według kryterium technicznego (controller, service, repository).

Metodologia zapożycza koncepcje z Domain-Driven Design (DDD) i Bounded Context: każda funkcja aplikacji to osobny bounded context z wyraźnymi granicami. Zmiany wewnątrz jednej funkcji nie powinny psuć innych funkcji, jeśli używają one tylko publicznego API slice'a. Według danych ankiety State of Frontend 2024, FSD zajmuje drugie miejsce pod względem popularności wśród architektur React (23%), ustępując tylko nieformalnej strukturze Feature-based (31%).

W rozwoju mobilnym FSD jest adaptowany do specyfiki modułów Android i frameworków iOS. W IT Sectr używamy FSD do projektów z 10+ ekranami i 3+ zespołami — metodologia pozwala na niezależny rozwój funkcji i zmniejsza liczbę konfliktów w git o 40% w porównaniu z monorepozytorium bez granic slice'ów.

Siedem warstw FSD: struktura i reguły importów

FSD definiuje siedem hierarchicznych warstw, z których każda zawiera kod o określonym poziomie abstrakcji. Główna reguła architektoniczna — warstwy mogą importować tylko kod z warstw niższych. Naruszenie tej reguły (import warstwy features w entities) jest uważane za błąd architektoniczny i blokowane przez linter.

Przykład struktury katalogów projektu FSD:

src/
├── app/                    // Warstwa aplikacji
│   ├── providers/
│   ├── router/
│   └── styles/
├── pages/                   // Strony — kompozycja funkcji
│   └── main/
├── features/                // Funkcje — scenariusze użytkownika
│   ├── auth/                // Slice «Autoryzacja»
│   │   ├── ui/
│   │   ├── model/
│   │   └── api/
│   └── productList/         // Slice «Lista produktów»
│       ├── ui/
│       └── model/
├── entities/                // Jednostki biznesowe
│   ├── user/
│   └── product/
├── widgets/                 // Komponenty kompozycyjne
│   └── header/
└── shared/                  // Wspólne narzędzia i UI-kit
    └── ui/

Reguła „warstwy patrzą tylko w dół" — kamień węgielny FSD. Jeśli funkcja auth importuje jednostkę user — jest to poprawne. Jeśli jednostka user zaczyna importować funkcję auth — jest to zależność cykliczna i naruszenie izolacji. Aby zapewnić przestrzeganie reguły, używa się wtyczek ESLint (eslint-plugin-fsd) lub własnych linterów publicznego API slice'ów.

Slice'y: granice domen biznesowych

Slice (wycinek) — podstawowa jednostka grupowania w FSD, odpowiadająca jednej funkcji biznesowej lub jednostce. Każdy slice znajduje się w jednej z siedmiu warstw (features, entities, widgets, pages) i zawiera pełny zestaw kodu do realizacji konkretnej funkcjonalności: komponenty UI, model danych, klient API, stałe i testy.

Granice slice'ów są określane przez domenę biznesową: funkcja auth obejmuje wszystko, co związane z autoryzacją (formularz logowania, formularz rejestracji, resetowanie hasła); jednostka user obejmuje model User, UserRepository i serializację. Granice nie powinny się przecinać: jeśli funkcja auth potrzebuje danych o użytkowniku — importuje jednostkę user, a nie kopiuje logikę. W rozwoju mobilnym slice FSD często odpowiada modułowi Gradle w Androidzie lub pakietowi Swift w iOS.

Slice'y są ściśle izolowane: wewnętrzna struktura jednego slice'a jest niewidoczna dla innych slice'ów. Do interakcji między slice'ami używa się publicznego API — pliku index.ts/index.js, który eksportuje tylko to, co jest dozwolone do użytku z zewnątrz. Cała reszta to moduły prywatne. Takie podejście zapobiega przypadkowym zależnościom i upraszcza refaktoryzację: zmiana prywatnej implementacji jednego slice'a nie wpływa na inne slice'y.

Segmenty: UI, API, Model, Lib wewnątrz slice'a

Wewnątrz każdego slice'a FSD kod jest dodatkowo organizowany według segmentów — kategorii technicznych, które powtarzają się we wszystkich slice'ach. Standardowy zestaw segmentów obejmuje ui (komponenty interfejsu), model (logika biznesowa, Store, Actions, Reducer), api (zapytania do serwera, mutacje), lib (narzędzia i helpery) oraz config (konfiguracja funkcji).

Segmenty to zalecenie, a nie ścisła reguła. Jeśli slice jest mały, segmenty można łączyć. W przypadku dużych slice'ów (funkcja z 10+ plikami) segmentacja jest obowiązkowa — bez niej wewnętrzna struktura szybko zamienia się w „kosz" z 50 plikami, gdzie znalezienie potrzebnego komponentu zajmuje minuty. W rozwoju mobilnym segmenty są często zastępowane strukturą plików według typu: każda funkcja to osobny plik Swift lub klasa Kotlin z wewnętrznymi typami.

FSD w rozwoju mobilnym: adaptacja pod Androida i iOS

W rozwoju mobilnym FSD jest adaptowany do cech platformowych — modułowej struktury Android (moduły Gradle) i Swift Package Manager. Adaptacja Android zakłada, że każdy slice to osobny moduł Gradle z własnym build.gradle. Moduły feature-auth, feature-profile, entity-user, shared-ui są od siebie izolowane na poziomie kompilacji: feature-auth nie może importować feature-profile, jeśli nie jest to określone w dependencies.

Adaptacja iOS opiera się na Swift Package Manager: każdy slice to pakiet Swift z publicznym API. W projektach TCA slice feature.auth zawiera własny Reducer, Store, View i klient API. Według danych Swift Community Survey 2024, 28% projektów iOS z TCA używa architektury slice'owej zbliżonej do FSD.

Głównym problemem adaptacji mobilnej FSD jest duplikowanie warstwy shared. W rozwoju mobilnym komponenty UI (shared/ui) często zależą od platformy (Android Views vs Jetpack Compose vs SwiftUI), co wymaga oddzielnych modułów shared dla każdej technologii. W FSD warstwa shared jest zazwyczaj niezależna od platformy (narzędzia, konfiguracje), a UI-kit jest wydzielany do osobnego modułu lub biblioteki komponentów.

Zalety i wady Feature-Sliced Design

Zalety FSD stają się widoczne w dużych projektach z 10+ programistami. Każdy programista lub zespół zajmuje się swoim slice'em, nie naruszając cudzego kodu. Konflikty w git zmniejszają się o 40–60% (dane z case studies feature-sliced.design). Nowe funkcje są dodawane bez ryzyka zepsucia istniejących, jeśli używają tylko publicznego API slice'ów. Refaktoryzacja jednej funkcji nie wymaga zmiany innych — wystarczy przepisać ui/model/api wewnątrz jednego slice'a, zachowując publiczne API.

Wady FSD — nadmierne zagnieżdżenie dla małych projektów. Jeśli aplikacja składa się z 3–5 ekranów, siedem warstw i segmentacja wewnątrz każdego slice'a tworzą więcej kodu organizacyjnego niż samej aplikacji. Próg wejścia jest wysoki: nowi programiści spędzają 2–4 tygodnie na opanowaniu metodologii. FSD jest również słabo kompatybilny z szybkim prototypowaniem — prototyp wymaga częstych cross-layer importów, które w FSD są zabronione i spowalniają iteracje.

Zaleca się rozpoczęcie od prostszej struktury Feature-based i migrację na FSD, gdy liczba ekranów przekroczy 20, a zespół — 5 programistów.