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

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

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

• 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.