refactor: move big from n to arch
This commit is contained in:
117
docs/architecture/04-fsd-feature-slice-design.md
Normal file
117
docs/architecture/04-fsd-feature-slice-design.md
Normal file
@@ -0,0 +1,117 @@
|
||||
---
|
||||
sidebar_position: 4
|
||||
---
|
||||
|
||||
# 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/ # Основная логика приложения (роутинг, провайдеры и т.д.)
|
||||
```
|
||||
### Понятия
|
||||
Слои, слайсы и сегменты образуют иерархию, как показано на схеме:
|
||||
|
||||
|
||||
На картинке выше: три столбика, обозначенные слева направо как `"Слои"`, `"Слайсы"` и `"Сегменты"` соответственно.
|
||||
|
||||
Столбик **"Слои"** содержит семь делений, расположенных сверху вниз и обозначенных "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_**
|
||||
Reference in New Issue
Block a user