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 c чёткими границами. Изменения внутри одной фичи не должны ломать другие фичи, если они используют только публичное 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% (данные feature-sliced.design case studies). Новые фичи добавляются без риска сломать существующие, если они используют только публичное API слайсов. Рефакторинг одной фичи не требует изменения других — достаточно переписать ui/model/api внутри одного слайса, сохранив публичное API.

Недостатки FSD — избыточная вложенность для маленьких проектов. Если приложение состоит из 3–5 экранов, семь слоёв и сегментация внутри каждого слайса создают больше кода организации, чем самого приложения. Порог входа высок: новые разработчики тратят 2–4 недели на освоение методологии. Также FSD плохо совместим с быстрым прототипированием — прототип требует частых cross-layer импортов, которые в FSD запрещены и замедляют итерации.

Рекомендуется начинать с более простой Feature-based структуры и мигрировать на FSD, когда количество экранов превысит 20, а команда — 5 разработчиков.