Feature-Sliced Design: суштина, методологија поделе на функционалности

Шта је Feature-Sliced Design?

Feature-Sliced Design (FSD) — методологија архитектуре фронтенд апликација, први пут предложена 2021. године од стране заједнице feature-sliced.design. Основна идеја FSD — груписање кода по пословним функцијама (слајсевима), од којих је свака самодовољна јединица: садржи сопствену пословну логику, кориснички интерфејс, рад са API-јем, моделе података и тестове. То разликује FSD од класичне слојевите архитектуре, где је код подељен по техничком критеријуму (controller, service, repository).

Методологија преузима концепте из Domain-Driven Design (DDD) и Bounded Context: свака функција апликације је засебан bounded context са јасним границама. Промене унутар једне функције не би требало да покваре друге функције, ако оне користе само јавни API слајса. Према подацима анкете State of Frontend 2024, FSD заузима друго место по популарности међу React архитектурама (23%), заостајући само за неформалном Feature-based структуром (31%).

У мобилном развоју, FSD се прилагођава специфичностима Android модула и iOS фрејмворка. У IT Sectr користимо FSD за пројекте са 10+ екрана и 3+ тима — методологија омогућава независан развој функција и смањује број конфликата у git-у за 40% у поређењу са монорепозиторијумом без граница слајсева.

Седам слојева FSD: структура и правила импорта

FSD дефинише седам хијерархијских слојева, од којих сваки садржи код одређеног нивоа апстракције. Главно архитектонско правило — слојеви могу да импортују само код из нижих слојева. Кршење овог правила (импорт слоја features у entities) сматра се архитектонском грешком и блокира се линтером.

Пример структуре директоријума FSD пројекта:

src/
├── app/                    // Слој апликације
│   ├── providers/
│   ├── router/
│   └── styles/
├── pages/                   // Странице — композиција функција
│   └── main/
├── features/                // Функције — кориснички сценарији
│   ├── auth/                // Слајс «Ауторизација»
│   │   ├── ui/
│   │   ├── model/
│   │   └── api/
│   └── productList/         // Слајс «Листа производа»
│       ├── ui/
│       └── model/
├── entities/                // Пословни ентитети
│   ├── user/
│   └── product/
├── widgets/                 // Композиционе компоненте
│   └── header/
└── shared/                  // Опште алатке и UI-kit
    └── ui/

Правило «слојеви гледају само надоле» — камен темељац FSD. Ако функција auth импортује ентитет user — то је исправно. Ако ентитет user почне да импортује функцију auth — то је циклична зависност и кршење изолације. За обезбеђивање поштовања правила користе се ESLint додаци (eslint-plugin-fsd) или сопствени линтери јавног API-ја слајсева.

Слајсеви: границе пословних домена

Слајс (slice) — основна јединица груписања у FSD, која одговара једној пословној функцији или ентитету. Сваки слајс се налази унутар једног од седам слојева (features, entities, widgets, pages) и садржи пун скуп кода за реализацију конкретне функционалности: UI компоненте, модел података, API клијент, константе и тестове.

Границе слајсева су одређене пословним доменом: функција auth укључује све што је везано за ауторизацију (форма за пријаву, форма за регистрацију, ресетовање лозинке); ентитет user укључује User модел, UserRepository и серијализацију. Границе се не смеју преклапати: ако функцији auth требају подаци о кориснику — она импортује ентитет user, а не копира логику. У мобилном развоју, слајс FSD често одговара Gradle модулу у Android-у или Swift пакету у iOS-у.

Слајсеви су строго изоловани: унутрашња структура једног слајса је невидљива за друге слајсеве. За интеракцију између слајсева користи се јавни API — датотека index.ts/index.js која извози само оно што је дозвољено за коришћење споља. Све остало су приватни модули. Овај приступ спречава случајне зависности и поједностављује рефакторисање: промена приватне имплементације једног слајса не утиче на друге слајсеве.

Сегменти: UI, API, Model, Lib унутар слајса

Унутар сваког FSD слајса, код се додатно организује по сегментима — техничким категоријама које се понављају у свим слајсевима. Стандардни скуп сегмената укључује ui (компоненте интерфејса), model (пословна логика, Store, Actions, Reducer), api (захтеви ка серверу, мутације), lib (алатке и хелпери) и config (конфигурација функције).

Сегменти су препорука, а не строго правило. Ако је слајс мали, сегменти се могу комбиновати. За велике слајсеве (функција са 10+ датотека), сегментација је обавезна — без ње унутрашња структура се брзо претвара у «корпу» од 50 датотека, где проналажење потребне компоненте траје минутима. У мобилном развоју, сегменти се често замењују структуром датотека по типу: свака функција је засебна Swift датотека или Kotlin класа са унутрашњим типовима.

FSD у мобилном развоју: адаптација за Android и iOS

У мобилном развоју, FSD се прилагођава платформским специфичностима — модуларној структури Android-а (Gradle модули) и Swift Package Manager-у. Android адаптација претпоставља да је сваки слајс засебан Gradle модул са својим build.gradle. Модули feature-auth, feature-profile, entity-user, shared-ui су изоловани један од другог на нивоу компајлирања: feature-auth не може да импортује feature-profile ако то није наведено у dependencies.

iOS адаптација се заснива на Swift Package Manager-у: сваки слајс је Swift пакет са јавним API-јем. У TCA пројектима, слајс feature.auth садржи сопствени Reducer, Store, View и API клијент. Према подацима Swift Community Survey 2024, 28% iOS пројеката са TCA користи слајс архитектуру блиску FSD.

Главни проблем мобилне адаптације FSD — дуплирање слоја shared. У мобилном развоју, UI компоненте (shared/ui) често зависе од платформе (Android Views vs Jetpack Compose vs SwiftUI), што захтева засебне shared модуле за сваку технологију. У FSD, shared слој је обично независан од платформе (алатке, конфигурације), а UI-kit се издваја у засебан модул или библиотеку компонената.

Предности и мане Feature-Sliced Design

Предности FSD постају видљиве у великим пројектима са 10+ програмера. Сваки програмер или тим се бави својим слајсом, не дирајући туђи код. Конфликти у git-у се смањују за 40–60% (подаци из case studies feature-sliced.design). Нове функције се додају без ризика да покваре постојеће, ако користе само јавни API слајсева. Рефакторисање једне функције не захтева измену других — довољно је прерадити ui/model/api унутар једног слајса, задржавајући јавни API.

Мане FSD — прекомерна угњежденост за мале пројекте. Ако се апликација састоји од 3–5 екрана, седам слојева и сегментација унутар сваког слајса стварају више организационог кода него саме апликације. Праг уласка је висок: нови програмери проводе 2–4 недеље на савладавање методологије. Такође, FSD је слабо компатибилан са брзим прототиповањем — прототип захтева честе cross-layer импорте, који су у FSD забрањени и успоравају итерације.

Препоручује се почети са једноставнијом Feature-based структуром и мигрирати на FSD када број екрана премаши 20, а тим — 5 програмера.