You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
**Feature-Sliced Design** (FSD) — это архитектурная методология для проектирования frontend-приложений. Проще говоря, это свод правил и соглашений по организации кода. Главная цель методологии — сделать проект понятным и структурированным, особенно в условиях регулярного изменения требований бизнеса.
13
13
14
-
Вот как это достигается:
14
+
## Подходит ли это мне? {#is-it-right-for-me}
15
15
16
-
- Крепкая основа из практик проектирования, **проверенных временем**:
17
-
_SOLID, GRASP, DDD, Separation of Concerns, Vertical Slices, Public API, Isolation._
18
-
- Разделение проекта по предметным областям согласно бизнес-логике
19
-
- Постоянство в файловой структуре
16
+
FSD подходит для проектов и команд любого размера с некоторыми оговорками:
20
17
21
-
Методология не привязана к конкретному стеку технологий и применима к большинству frontend-приложений. Документация содержит примеры реализации на JavaScript + React, но FSD успешно адаптируется и к другим комбинациям инструментов (см. [примеры проектов][refs-examples]).
18
+
- Эта методология исключительно для фронтенда. Если вы ищете архитектуру для бэкенда, обратите внимание на [Clean Architecture][refs-clean-architecture].
19
+
- Если вы разрабатываете очень простое приложение из одной странички на FSD, преимущества методологии вряд ли понадобятся, а вот разработка может замедлиться. Однако, FSD помогает стандартизированно мыслить о фронтенд-приложениях, так что смело используйте даже на маленьких проектах, если знаете, для чего она вам.
20
+
- Огромное приложение, соизмеримое с админ-панелью Google Cloud, потребует специализированной архитектуры. FSD в данном случае может выступать в качестве отправной точки.
22
21
23
-
## Основы {#basics}
22
+
Методология не привязана к конкретному языку программирования, UI-фреймворку или менеджеру состояния — подойдет любой (см. [примеры использования][refs-examples]).
23
+
24
+
Если у вас уже есть проект, не переживайте — FSD можно внедрять постепенно. Главный вопрос, который стоит задать команде: "**Eсть ли боль** при разработке проекта?" Если боли нет, возможно, переход делать не стоит.
25
+
26
+
## Краткий обзор {#overview}
27
+
28
+
Проект на FSD состоит из _слоев_ (layers), каждый слой состоит из _слайсов_ (slices) и каждый слайс состоит из _сегментов_ (segments).
24
29
25
30
26
31
27
-
Термины, обозначенные на схеме, подробно описаны в разделе [**Abstractions**][refs-basics--abstractions].
32
+
Слои стандартизированы во всех проектах и расположены вертикально. Модули на одном слое могут взаимодействовать лишь с модулями, находящимися на слоях строго ниже. На данный момент слоев семь (снизу вверх):
33
+
34
+
1.**Shared** — переиспользуемый код, не имеющий отношения к специфике приложения/бизнеса.
35
+
2.**Entities** (сущности) — бизнес-сущности (например, User, Product или Order).
36
+
3.**Features** (фичи) — взаимодействия с пользователем, действия, которые несут бизнес-ценность для пользователя.
37
+
4.**Widgets** (виджеты) — композиционный слой для соединения сущностей и фич в самостоятельные блоки.
38
+
5.**Pages** (страницы) — композиционный слой для сборки полноценных страниц из сущностей, фич и виджетов.
39
+
6.**Processes** — сложные сценарии, покрывающие несколько страниц (например, аутентификация).
40
+
7.**App** — настройки, стили и провайдеры для всего приложения.
41
+
42
+
Затем есть слайсы, разделяющие код по предметной области. Они группируют логически связанные модули, что облегчает навигацию по кодовой базе. Слайсы не могут использовать другие слайсы на том же слое, что обеспечивает высокий уровень [_связности_][refs-wiki-cohesion] (cohesion) при низком уровне [_связанности_][refs-wiki-coupling] (coupling).
43
+
44
+
В свою очередь, каждый слайс состоит из сегметнов. Это маленькие модули, главная задача которых — разделить код внутри слайса по техническому назначению. Самые распространенные сегменты — `ui`, `model`, `api` и `lib`, но в вашем слайсе может не быть каких-то сегментов, могут быть другие, по вашему усмотрению.
45
+
46
+
### Пример декомпозиции {#decomposition-example}
47
+
48
+
Рассмотрим приложение социальной сети.
28
49
29
-
Подобная структура имеет ряд преимуществ:
50
+
*`app/` содержит настройку роутера, глобальные хранилища и стили.
51
+
*`processes/` содержит часть аутентификации, отвечающую за чтение/запись токенов аутентификации.
52
+
*`pages/` содержит компоненты роутов на каждую страницу в приложении, преимущественно композирующие, по возможности, без собственной логики.
53
+
54
+
В рамках этого приложения рассмотрим карточку поста в ленте новостей.
55
+
56
+
*`widgets/` содержит "собранную" карточку поста, с содержимым и интерактивными кнопками, в которые вшиты запросы к бэкенду.
57
+
*`features/` содержит всю интерактивность карточки (например, кнопку лайка) и логику обработки этой интерактивности.
58
+
*`entities/` содержит скелет карточки со слотами под интерактивные элементы. Компонент, демонстрирующий автора поста, также находится в этой папке, но в другом слайсе.
59
+
60
+
### Преимущества {#advantages}
30
61
31
62
-**Единообразие**
32
63
Код распределяется согласно области влияния (слой), предметной области (слайс) и техническому назначению (сегмент).
Один модуль не может использовать другой модуль, расположенный на том же слое или на слоях выше.
41
72
Благодаря этому приложение можно изолированно модифицировать под новые требования без непредвиденных последствий.
42
73
43
-
-**Масштабирование проекта и команды**
44
-
Увеличение функциональности ведет к значительно меньшему усложнению проекта, т.к. вся логика распределена изолированно, и это распределение определяется однозначно.
45
-
Благодаря этому легко вводить новых людей в проект/команду, а также расширять функциональность проекта.
46
74
75
+
## Постепенное внедрение {#incremental-adoption}
76
+
77
+
Сила FSD в _структурированной_ декомпозиции. В лучшей форме, FSD позволяет найти место для любой части кода почти однозначно. Однако, уровень декомпозиции — это параметр, и любая команда может подстроить его для оптимального баланса между легкостью внедрения и преимуществами.
47
78
48
-
## Мотивация {#motivation}
79
+
Предлагаем следующую стратегию для миграции существующей кодовой базы на FSD, проверенную опытом:
49
80
50
-
Обычно, подходы построения архитектуры фронтенда от проекта к проекту переизобретаются с нуля, пополняя "проектные знания". При этом неверно принятые решения зачастую приводят к проблемам масштабируемости проекта и команды. Поэтому вместо того, чтобы придумывать и документировать это каждый раз, хочется **обобщить опыт и сформировать рабочую, проверенную и задокументированную методологию** для проектирования архитектуры фронтенда.
81
+
1. Вырезать слои `app` и `shared`, чтобы иметь опору для последующих этапов. Эти слои получатся тонкими и простыми, пусть такими и остаются.
51
82
52
-
В разделе [**Мотивация**][refs-motivation] подробно описаны причины возникновения методологии, а также сравнение с другими подходами.
53
-
В разделе [**Об архитектуре**][refs-architecture] перечислены типичные проблемы проектов, а также требования к идеальной архитектуре, которых стремится придерживаться Feature-Sliced Design.
83
+
2. Вынести весь интерфейс, связанный с бизнесом, распределить по виджетам и страницам, даже если в них пока что будут зависимости, нарушающие правила FSD.
84
+
85
+
3. Постепенно наращивать степень декомпозиции, выделяя `features` и `entities`. Превращать страницы и виджеты из перегруженных логикой слоёв в чисто композиционные слои.
86
+
87
+
Рекомендуется воздержаться от добавления новых крупных сущностей во время рефакторинга, а также рефакторинга по частям.
54
88
55
89
## Что дальше? {#whats-next}
56
90
@@ -107,7 +141,8 @@ import Link from "@docusaurus/Link";
0 commit comments