---
sidebar_position: 5
---

# Feature slice design

**Feature Slice Design (FSD)** — это методология проектирования и организации кода во фронтенд-разработке, которая фокусируется на разделении приложения на независимые, функционально завершённые блоки (срезы), каждый из которых соответствует определённой фиче (функциональности) продукта. Этот подход помогает создавать более структурированные, масштабируемые и поддерживаемые приложения.

## Основные идеи FSD:
1. **Организация по фичам, а не по типам файлов:**
   - Вместо традиционного разделения на папки типа `components`, `pages`, `store`, код организуется вокруг функциональных блоков (фич).
   - Например, для фичи "Корзина покупок" создаётся отдельная папка, внутри которой находятся все связанные с ней компоненты, стили, логика и тесты.
2. **Изоляция функциональности:**
   - Каждая фича (срез) максимально независима от других. Это позволяет разрабатывать, тестировать и изменять её без влияния на остальные части приложения.
3. **Переиспользуемость:**
   - Общие части (например, UI-компоненты или утилиты) выносятся в отдельный слой, который может использоваться несколькими фичами.
4. **Масштабируемость:**
   - По мере роста приложения новые фичи добавляются как отдельные модули, что упрощает поддержку и развитие проекта.

### Пример структуры проекта с использованием FSD:
```
src/
│
├── features/
│   ├── cart/              # Фича "Корзина"
│   │   ├── components/    # Компоненты, специфичные для корзины
│   │   ├── hooks/         # Хуки для корзины
│   │   ├── store/         # Логика состояния (например, Redux slice)
│   │   └── index.ts       # Экспорт фичи
│   │
│   └── auth/              # Фича "Авторизация"
│       ├── components/
│       ├── hooks/
│       ├── store/
│       └── index.ts
│
├── shared/                # Общие компоненты и утилиты
│   ├── ui/                # UI-компоненты (кнопки, инпуты и т.д.)
│   └── lib/               # Утилиты и хелперы
│
└── app/                   # Основная логика приложения (роутинг, провайдеры и т.д.)
```
### Понятия
Слои, слайсы и сегменты образуют иерархию, как показано на схеме:
![](images/05-fsd-1.png)

На картинке выше: три столбика, обозначенные слева направо как `"Слои"`, `"Слайсы"` и `"Сегменты"` соответственно.

Столбик **"Слои"** содержит семь делений, расположенных сверху вниз и обозначенных "app", "processes", "pages", "widgets", "features", "entities" и "shared". Деление "processes" зачеркнуто. Деление "entities" соединено со вторым столбиком "Слайсы", показывая, что второй столбик является содержимым "entities".

Столбик **"Слайсы"** содержит три деления, расположенных сверху вниз и обозначенных "user", "post" и "comment". Деление "post" соединено со столбиком "Сегменты" таким же образом, что и содержимое "post".

Столбик **"Сегменты"** содержит три деления, расположенных сверху вниз и обозначенных "ui", "model" и "api".

### Слои
Слои стандартизированы во всех проектах FSD. Вам не обязательно использовать все слои, но их названия важны. На данный момент их семь (сверху вниз):

1. **App** — всё, благодаря чему приложение запускается — роутинг, точки входа, глобальные стили, провайдеры и т. д.
2. **Processes (процессы, устаревший)** — сложные межстраничные сценарии.
3. **Pages (страницы)** — полные страницы или большие части страницы при вложенном роутинге.
4. **Widgets (виджеты)** — большие самодостаточные куски функциональности или интерфейса, обычно реализующие целый пользовательский сценарий.
5. **Features (фичи)** — повторно используемые реализации целых фич продукта, то есть действий, приносящих бизнес-ценность пользователю.
6. **Entities (сущности)** — бизнес-сущности, с которыми работает проект, например user или product.
7. **Shared** — переиспользуемый код, особенно когда он отделён от специфики проекта/бизнеса, хотя это не обязательно.

Слои **App** и **Shared**, в отличие от других слоев, не имеют слайсов и состоят из сегментов напрямую.

Фишка слоев в том, что модули на одном слое могут знать только о модулях со слоев строго ниже, и как следствие, импортировать только с них.

### Слайсы
Дальше идут слайсы, они делят слой по предметной области. Вы можете называть ваши слайсы как угодно, и создавать их сколько угодно. Слайсы помогают не теряться в проекте, потому что группируют тесно связанный по смыслу код.

Слайсы не могут использовать другие слайсы на том же слое, и это обеспечивает сильную связанность кода внутри слайса и слабую сцепленность между слайсами.

### Сегменты
Слайсы, а также слои App и Shared, состоят из сегментов, а сегменты группируют код по его назначению. Имена сегментов не зафиксированы стандартом, но существует несколько общепринятых имен для наиболее распространенных целей:

- `ui` — всё, что связано с отображением: UI-компоненты, форматтеры дат, стили и т.д.
- `api` — взаимодействие с бэкендом: функции запросов, типы данных, мапперы.
- `model` — модель данных: схемы валидации, интерфейсы, хранилища и бизнес-логика.
- `lib` — библиотечный код, который нужен другим модулям этого слайса.
- `config` — файлы конфигурации и фиче-флаги.
Обычно этих сегментов достаточно для большинства слоев, поэтому свои собственные сегменты обычно создают только в Shared или App, но это не жёсткое правило.

### Преимущества
- **Однородность** \
  Поскольку структура стандартизирована, проекты становятся более единообразными, что облегчает набор новых участников в команду.
- **Устойчивость к изменениям и рефакторингу** \
  Модуль на одном слое не может использовать другие модули на том же слое или слоях выше. \
  Это позволяет вам вносить изолированные правки без непредвиденных последствий для остальной части приложения.
- **Контролируемое переиспользование логики** \
  В зависимости от уровня вы можете сделать код либо очень переиспользуемым, либо очень локальным.\
  Это сохраняет баланс между соблюдением принципа DRY и практичностью.
- **Ориентация на потребности бизнеса и пользователей** \
  Приложение разделено на бизнес-домены, и при именовании поощряется использование терминологии бизнеса, чтобы вы могли делать полезную работу в продукте, не вникая полностью во все другие несвязанные части проекта.

## Когда использовать Feature Slice Design
- В крупных проектах с большим количеством функциональных блоков.
- В командах, где разные разработчики работают над разными фичами.
- Когда требуется высокая степень переиспользуемости и модульности.

## Преимущества FSD:
- **Упрощение разработки:** Легче фокусироваться на одной фиче, не отвлекаясь на остальные части приложения.
- **Улучшение поддерживаемости:** Изменения в одной фиче не затрагивают другие.
- **Гибкость:** Фичи можно легко добавлять, удалять или заменять.
- **Тестируемость:** Каждая фича может быть протестирована изолированно.

## Когда использовать FSD:
- В крупных проектах с множеством функциональных блоков.
- Когда требуется высокая степень переиспользуемости и модульности.
- В командах, где разные разработчики работают над разными фичами.

## Альтернативы:
- **Layer-based architecture** (разделение на слои, например, components, pages, store).
- **Domain-driven design (DDD)** (организация кода вокруг доменных областей).

🚀 **_Источник: DeepSeek_**