Feature-Sliced Design: podstata, metodologie rozdělení na funkce

Co je Feature-Sliced Design?

Feature-Sliced Design (FSD) — metodologie architektury frontendových aplikací, poprvé navržená v roce 2021 komunitou feature-sliced.design. Hlavní myšlenkou FSD je seskupování kódu podle obchodních funkcí (sliceů), z nichž každá je soběstačnou jednotkou: obsahuje vlastní obchodní logiku, uživatelské rozhraní, práci s API, datové modely a testy. To odlišuje FSD od klasické vrstevnaté architektury, kde je kód rozdělen podle technického kritéria (controller, service, repository).

Metodologie si vypůjčuje koncepty z Domain-Driven Design (DDD) a Bounded Context: každá funkce aplikace je samostatný bounded context s jasnými hranicemi. Změny uvnitř jedné funkce by neměly poškodit ostatní funkce, pokud používají pouze veřejné API sliceu. Podle údajů průzkumu State of Frontend 2024 zaujímá FSD druhé místo v popularitě mezi architekturami React (23%), zaostává pouze za neformální strukturou Feature-based (31%).

V mobilním vývoji se FSD přizpůsobuje specifikům modulů Android a frameworků iOS. V IT Sectr používáme FSD pro projekty s 10+ obrazovkami a 3+ týmy — metodologie umožňuje nezávislý vývoj funkcí a snižuje počet konfliktů v gitu o 40% ve srovnání s monorepozitářem bez hranic sliceů.

Sedm vrstev FSD: struktura a pravidla importů

FSD definuje sedm hierarchických vrstev, z nichž každá obsahuje kód určité úrovně abstrakce. Hlavní architektonické pravidlo — vrstvy mohou importovat pouze kód z nižších vrstev. Porušení tohoto pravidla (import vrstvy features v entities) je považováno za architektonickou chybu a je blokováno linterem.

Příklad adresářové struktury projektu FSD:

src/
├── app/                    // Vrstva aplikace
│   ├── providers/
│   ├── router/
│   └── styles/
├── pages/                   // Stránky — kompozice funkcí
│   └── main/
├── features/                // Funkce — uživatelské scénáře
│   ├── auth/                // Slice autentizace
│   │   ├── ui/
│   │   ├── model/
│   │   └── api/
│   └── productList/         // Slice seznamu produktů
│       ├── ui/
│       └── model/
├── entities/                // Obchodní entity
│   ├── user/
│   └── product/
├── widgets/                 // Kompoziční komponenty
│   └── header/
└── shared/                  // Obecné nástroje a UI-kit
    └── ui/

Pravidlo vrstvy se dívají pouze dolů — základní kámen FSD. Pokud funkce auth importuje entitu user — je to správně. Pokud entita user začne importovat funkci auth — jde o cyklickou závislost a porušení izolace. Pro zajištění dodržování pravidla se používají ESLint pluginy (eslint-plugin-fsd) nebo vlastní lintery veřejného API sliceů.

Slicey: hranice obchodních domén

Slice — základní jednotka seskupování v FSD, odpovídající jedné obchodní funkci nebo entitě. Každý slice se nachází v jedné ze sedmi vrstev (features, entities, widgets, pages) a obsahuje kompletní sadu kódu pro implementaci konkrétní funkcionality: UI komponenty, datový model, API klient, konstanty a testy.

Hranice sliceů jsou určeny obchodní doménou: funkce auth zahrnuje vše spojené s autentizací (přihlašovací formulář, registrační formulář, resetování hesla); entita user zahrnuje model User, UserRepository a serializaci. Hranice by se neměly překrývat: pokud funkce auth potřebuje data o uživateli — importuje entitu user, místo kopírování logiky. V mobilním vývoji slice FSD často odpovídá modulu Gradle v Androidu nebo balíčku Swift v iOS.

Slicey jsou přísně izolovány: vnitřní struktura jednoho sliceu je neviditelná pro ostatní slicey. Pro interakci mezi slicey se používá veřejné API — soubor index.ts/index.js, který exportuje pouze to, co je povoleno používat zvenčí. Vše ostatní jsou soukromé moduly. Tento přístup zabraňuje náhodným závislostem a zjednodušuje refaktorování: změna soukromé implementace jednoho sliceu neovlivňuje ostatní slicey.

Segmenty: UI, API, Model, Lib uvnitř sliceu

Uvnitř každého FSD sliceu je kód dále organizován podle segmentů — technických kategorií, které se opakují ve všech sliceích. Standardní sada segmentů zahrnuje ui (komponenty rozhraní), model (obchodní logika, Store, Actions, Reducer), api (požadavky na server, mutace), lib (nástroje a helpery) a config (konfigurace funkce).

Segmenty jsou doporučení, nikoli přísné pravidlo. Pokud je slice malý, segmenty lze sloučit. Pro velké slicey (funkce s 10+ soubory) je segmentace povinná — bez ní se vnitřní struktura rychle změní v košík s 50 soubory, kde nalezení potřebné komponenty trvá minuty. V mobilním vývoji jsou segmenty často nahrazovány strukturou souborů podle typu: každá funkce je samostatný Swift soubor nebo třída Kotlin s vnitřními typy.

FSD v mobilním vývoji: adaptace pro Android a iOS

V mobilním vývoji se FSD přizpůsobuje platformním specifikům — modulární struktuře Androidu (moduly Gradle) a Swift Package Manageru. Adaptace Android předpokládá, že každý slice je samostatný modul Gradle s vlastním build.gradle. Moduly feature-auth, feature-profile, entity-user, shared-ui jsou od sebe izolovány na úrovni kompilace: feature-auth nemůže importovat feature-profile, pokud to není uvedeno v dependencies.

Adaptace iOS je založena na Swift Package Manageru: každý slice je balíček Swift s veřejným API. V projektech TCA obsahuje slice feature.auth vlastní Reducer, Store, View a API klienta. Podle údajů Swift Community Survey 2024 používá 28% iOS projektů s TCA sliceovou architekturu blízkou FSD.

Hlavním problémem mobilní adaptace FSD je duplikování vrstvy shared. V mobilním vývoji jsou UI komponenty (shared/ui) často závislé na platformě (Android Views vs Jetpack Compose vs SwiftUI), což vyžaduje samostatné shared moduly pro každou technologii. V FSD je vrstva shared obvykle nezávislá na platformě (nástroje, konfigurace) a UI-kit je vyčleněn do samostatného modulu nebo knihovny komponent.

Výhody a nevýhody Feature-Sliced Design

Výhody FSD se projevují ve velkých projektech s 10+ vývojáři. Každý vývojář nebo tým se zabývá svým sliceem, aniž by zasahoval do cizího kódu. Konflikty v gitu se snižují o 40–60% (údaje z case studies feature-sliced.design). Nové funkce se přidávají bez rizika poškození stávajících, pokud používají pouze veřejné API sliceů. Refaktorování jedné funkce nevyžaduje změnu ostatních — stačí přepsat ui/model/api uvnitř jednoho sliceu při zachování veřejného API.

Nevýhody FSD — nadměrné vnoření pro malé projekty. Pokud aplikace sestává ze 3–5 obrazovek, sedm vrstev a segmentace uvnitř každého sliceu vytváří více organizačního kódu než samotná aplikace. Práh vstupu je vysoký: noví vývojáři stráví 2–4 týdny osvojováním metodologie. FSD je také špatně kompatibilní s rychlým prototypováním — prototyp vyžaduje časté cross-layer importy, které jsou v FSD zakázány a zpomalují iterace.

Doporučuje se začít s jednodušší strukturou Feature-based a migrovat na FSD, když počet obrazovek přesáhne 20 a tým — 5 vývojářů.