Feature-Sliced Design: lényeg, a funkciókra bontás módszertana

Mi az a Feature-Sliced Design?

Feature-Sliced Design (FSD) — a frontend alkalmazások architektúrájának módszertana, amelyet először 2021-ben javasolt a feature-sliced.design közösség. Az FSD fő gondolata — a kód csoportosítása üzleti funkciók (szeletek) szerint, amelyek mindegyike egy önellátó egység: tartalmazza a saját üzleti logikáját, felhasználói felületét, API-működését, adatmodelljeit és tesztjeit. Ez különbözteti meg az FSD-t a klasszikus réteges architektúrától, ahol a kód technikai szempont szerint van felosztva (controller, service, repository).

A módszertan a Domain-Driven Design (DDD) és a Bounded Context koncepcióit kölcsönzi: az alkalmazás minden funkciója egy külön bounded context, világos határokkal. Az egyik funkción belüli változtatások nem ronthatják el a többi funkciót, ha azok csak a szelet nyilvános API-ját használják. A State of Frontend 2024 felmérés adatai szerint az FSD a második helyen áll a népszerűségben a React architektúrák között (23%), csak az informális Feature-based struktúra (31%) előzi meg.

A mobilfejlesztésben az FSD az Android-modulok és iOS-keretrendszerek sajátosságaihoz igazodik. Az IT Sectr-ben az FSD-t 10+ képernyős és 3+ csapatos projektekhez használjuk — a módszertan lehetővé teszi a funkciók független fejlesztését, és 40%-kal csökkenti a git-konfliktusok számát a szelethatárok nélküli monorepozitóriumhoz képest.

Az FSD hét rétege: struktúra és importálási szabályok

Az FSD hét hierarchikus réteget határoz meg, amelyek mindegyike egy bizonyos absztrakciós szintű kódot tartalmaz. A fő architekturális szabály — a rétegek csak az alattuk lévő rétegekből importálhatnak kódot. Ennek a szabálynak a megsértése (a features réteg importálása entities-ben) architekturális hibának minősül, és a linter blokkolja.

Példa egy FSD-projekt könyvtárszerkezetére:

src/
├── app/                    // Alkalmazás rétege
│   ├── providers/
│   ├── router/
│   └── styles/
├── pages/                   // Oldalak — funkciók kompozíciója
│   └── main/
├── features/                // Funkciók — felhasználói forgatókönyvek
│   ├── auth/                // Hitelesítés szelet
│   │   ├── ui/
│   │   ├── model/
│   │   └── api/
│   └── productList/         // Terméklista szelet
│       ├── ui/
│       └── model/
├── entities/                // Üzleti entitások
│   ├── user/
│   └── product/
├── widgets/                 // Kompozíciós komponensek
│   └── header/
└── shared/                  // Általános segédprogramok és UI-kit
    └── ui/

A rétegek csak lefelé néznek szabály — az FSD sarokköve. Ha az auth funkció importálja a user entitást — ez helyes. Ha a user entitás elkezdi importálni az auth funkciót — ez ciklikus függőség és az elkülönítés megsértése. A szabály betartásának biztosításához ESLint-bővítményeket (eslint-plugin-fsd) vagy a szeletek nyilvános API-jának saját lintjeit használják.

Szeletek: az üzleti tartományok határai

A szelet (slice) — az FSD alapvető csoportosítási egysége, amely egy üzleti funkciónak vagy entitásnak felel meg. Minden szelet a hét réteg egyikében (features, entities, widgets, pages) található, és tartalmazza a teljes kódkészletet egy adott funkció megvalósításához: UI-komponensek, adatmodell, API-kliens, konstansok és tesztek.

A szeletek határait az üzleti tartomány határozza meg: az auth funkció magában foglal mindent, ami a hitelesítéssel kapcsolatos (bejelentkezési űrlap, regisztrációs űrlap, jelszó-visszaállítás); a user entitás magában foglalja a User modellt, UserRepository-t és a szerializációt. A határok nem fedhetik egymást: ha az auth funkciónak felhasználói adatokra van szüksége — importálja a user entitást, nem másolja a logikát. A mobilfejlesztésben az FSD szelet gyakran egy Gradle-modulnak felel meg Androidon vagy egy Swift-csomagnak iOS-en.

A szeletek szigorúan elkülönülnek: egy szelet belső szerkezete láthatatlan a többi szelet számára. A szeletek közötti interakcióhoz a nyilvános API-t használják — az index.ts/index.js fájlt, amely csak azt exportálja, amit kívülről szabad használni. Minden más privát modul. Ez a megközelítés megakadályozza a véletlen függőségeket és leegyszerűsíti a refaktorálást: egy szelet privát megvalósításának megváltoztatása nem érinti a többi szeletet.

Szegmensek: UI, API, Model, Lib a szeleten belül

Minden FSD szeleten belül a kód további szegmensek szerint van szervezve — technikai kategóriák, amelyek minden szeletben ismétlődnek. A szabványos szegmenscsoport tartalmazza: ui (felületi komponensek), model (üzleti logika, Store, Actions, Reducer), api (szerverkérelmek, mutációk), lib (segédprogramok és helperek) és config (funkció konfigurációja).

A szegmensek ajánlások, nem szigorú szabályok. Ha a szelet kicsi, a szegmensek összevonhatók. Nagy szeleteknél (10+ fájlos funkció) a szegmentálás kötelező — enélkül a belső struktúra gyorsan egy 50 fájlos kosárrá válik, ahol a szükséges komponens megtalálása percekig tart. A mobilfejlesztésben a szegmenseket gyakran fájlszerkezet váltja fel típus szerint: minden funkció egy külön Swift-fájl vagy Kotlin-osztály belső típusokkal.

FSD a mobilfejlesztésben: adaptáció Androidra és iOS-re

A mobilfejlesztésben az FSD a platform-specifikus jellemzőkhöz igazodik — az Android moduláris szerkezetéhez (Gradle-modulok) és a Swift Package Manager-hez. Android-adaptáció feltételezi, hogy minden szelet egy külön Gradle-modul a saját build.gradle fájljával. A feature-auth, feature-profile, entity-user, shared-ui modulok fordítási szinten el vannak különítve egymástól: a feature-auth nem importálhatja a feature-profile-t, ha az nincs megadva a dependencies-ben.

iOS-adaptáció a Swift Package Manager-en alapul: minden szelet egy Swift-csomag nyilvános API-val. A TCA-projektekben a feature.auth szelet tartalmazza a saját Reducer-t, Store-t, View-t és API-klienst. A Swift Community Survey 2024 adatai szerint a TCA-val rendelkező iOS-projektek 28%-a az FSD-hez közeli szeletarchitektúrát használ.

A mobil FSD-adaptáció fő problémája — a shared réteg duplikálása. A mobilfejlesztésben az UI-komponensek (shared/ui) gyakran platformfüggők (Android Views vs Jetpack Compose vs SwiftUI), ami külön shared-modulokat igényel minden technológiához. Az FSD-ben a shared réteg általában platformfüggetlen (segédprogramok, konfigurációk), az UI-kit pedig külön modulba vagy komponenskönyvtárba kerül.

A Feature-Sliced Design előnyei és hátrányai

Előnyök Az FSD előnyei nagy, 10+ fejlesztős projektekben válnak láthatóvá. Minden fejlesztő vagy csapat a saját szeletével foglalkozik, nem nyúl mások kódjához. A git-konfliktusok 40–60%-kal csökkennek (feature-sliced.design esettanulmányok adatai). Új funkciók a meglévők elrontásának kockázata nélkül adhatók hozzá, ha csak a szeletek nyilvános API-ját használják. Egy funkció refaktorálása nem igényli mások módosítását — elég átírni az ui/model/api-t egy szeleten belül, megtartva a nyilvános API-t.

Hátrányok Az FSD hátránya — túlzott egymásba ágyazás kis projekteknél. Ha az alkalmazás 3–5 képernyőből áll, hét réteg és szegmentálás minden szeleten belül több szervezési kódot hoz létre, mint maga az alkalmazás. A belépési küszöb magas: az új fejlesztők 2–4 hetet töltenek a módszertan elsajátításával. Az FSD rosszul kompatibilis a gyors prototípuskészítéssel is — a prototípus gyakori cross-layer importálást igényel, ami az FSD-ben tilos és lassítja az iterációkat.

Ajánlott egyszerűbb Feature-based struktúrával kezdeni, és FSD-re migrálni, amikor a képernyők száma meghaladja a 20-at, a csapat pedig az 5 fejlesztőt.