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. Якщо feature auth імпортує entity user — це коректно. Якщо entity user починає імпортувати feature auth — це циклічна залежність та порушення ізоляції. Для забезпечення правила використовуються ESLint-плагіни (eslint-plugin-fsd) або власні лінтери публічного API слайсів.

Слайси: межі бізнес-доменів

Слайс (slice) — основна одиниця групування в FSD, що відповідає одній бізнес-фічі або сутності. Кожен слайс знаходиться всередині одного з семи шарів (features, entities, widgets, pages) та містить повний набір коду для реалізації конкретної функціональності: UI-компоненти, модель даних, API-клієнт, константи та тести.

Межі слайсів визначаються бізнес-доменом: feature auth включає все, що пов'язано з авторизацією (форма входу, форма реєстрації, скидання пароля); entity user включає User-модель, UserRepository та серіалізацію. Межі не повинні перетинатися: якщо в feature auth потрібні дані про користувача — вона імпортує entity user, а не копіює логіку. У мобільній розробці слайс FSD часто відповідає Gradle-модулю в Android або Swift-пакету в iOS.

Слайси строго ізольовані: внутрішня структура одного слайса невидима для інших слайсів. Для взаємодії між слайсами використовується публічний API — файл index.ts/index.js, який експортує тільки те, що дозволено до використання ззовні. Все інше — приватні модулі. Такий підхід запобігає випадковим залежностям і спрощує рефакторинг: зміна приватної реалізації одного слайса не зачіпає інші слайси.

Сегменти: UI, API, Model, Lib всередині слайса

Всередині кожного слайса FSD код додатково організується за сегментами — технічними категоріями, які повторюються у всіх слайсах. Стандартний набір сегментів включає ui (компоненти інтерфейсу), model (бізнес-логіка, Store, Actions, Reducer), api (запити до сервера, мутації), lib (утиліти та хелпери) та config (конфігурація фічі).

Сегменти — рекомендація, а не строге правило. Якщо слайс маленький, сегменти можна об'єднувати. Для великих слайсів (feature з 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 розробників.