Архитектура фронтенда на основе вертикальных слайсов⁠⁠

Сегодня порекомендую статью о структуре фронтенд проектов на основе вертикальных слайсов.

Автор начинает рассказ с описания структур первых проектов, где использовался подход “Разделения по техническим слоям”, в котором мы группируем файлы по функциональности, а не по доменной области:

- api/services
- components
- stores
- constants
- и т.д.

и затем описывается, как этот подход всё ещё используется внутри “вертикальных слайсов”.

Разделение по техническим слоям

✅ Плюсы подхода

- хорошо работает для маленьких проектов
- у слоев есть однонаправленный поток использования, и нельзя импортировать файлы из слоев, находящихся на уровне выше (например сторы могут использовать api, а страницы могут использовать базовые компоненты, но не наоборот).

❌ Проблемы подхода

- Даже для небольших продуктовых фичей приходится править код по всему проекту, так как он раскидан по разным папкам
- Неявные связи в рамках конкретных слоев: бизнес компоненты (ProductCard, UserProfile) смешиваются c UI компонентами (Link, Button) в components, то же самое касается бизнес логики

«Vertical sliced» подход

Подход подразумевает, что архитектура строится не вокруг технических слоев, а поверх конкретных слайсов проекта.

По сути, мы берём структуру “разделения по техническим слоям” и делаем разрез по фичам. То есть, создаём папку для каждой фичи, внутри которой все файлы относятся только к этой фиче и “разделены по техническим слоям”.

ℹ️ Описание папок

- shared - тут хранятся всё, что можно переиспользовать и не зависит от определённой бизнес фичи. Например в shared/components будут лежать, обычные кнопки, радио кнопки и прочее
- domain - базовый UI для бизнес-сущностей (домена) проекта, например карточка товара. Простая аналогия (но не совсем правильная) - в домене можно хранить все то, что хранится в базе данных на бекенде.
- features - самодостаточные компоненты — большие бизнес сущности приложения, например корзина. Для реализации фичи, скорее всего будет использоваться несколько компонентов из доменной области.
- pages - страницы приложения.

✅ Плюсы подхода

- Когда необходимо внести изменения в фичу — все изменения происходят внутри одного слайса.
- На выходе получаем высокое зацепление (high cohesion) внутри слайса и низкую связанность (low coupling) между разными слайсами
- Сохраняется правило однонапревленного использвания: pages ⇒ features ⇒ domain ⇒ shared
- Фичи не могут напрямую использовать друг друга
- На самом нижнем уровне используется “разделение по техническим слоям”

Чтобы обеспечить однонаправленный поток использования можно взять eslint c плагином import/no-restricted-paths.

https://t.me/cherkashindev/128