Паттерны
October 9, 2023

Feature Sliced архитектура web-приложения

Бизнес-ориентированный подход, суть которого заключается в строго регламентированном взаимодействии трех основных сущностей:

  • Слой
  • Слайс
  • Сегменты

Структура:

Слой (layer)

  • Каждый слой стандартизирован, но опционален
  • Слои располагаются вертикально и обозначают зону ответственности
  • Модули на одном слое взаимодействуют только с модулями на слоях ниже
  • Слои выше:
    • Более привязаны к предметной области и тем
    • Содержат больше бизнес-логики
    • Более самостоятельные
  • Слои ниже:
    • Более абстрактны и переиспользуемые
    • Менее самостоятельные

Описание слоев:

  • shared
    • Gереиспользуемый код, не имеющий отношения к специфике приложения (UIKit, libs, API)
  • entities
    • Бизнес-сущности (User, Product, Order)
  • features
    • Пользовательские действия, которые несут бизнес-ценность (SendComment, AddToCart, UsersSearch)
  • widgets
    • Композиционный слой для соединения сущностей и фич в самостоятельные блоки (IssuesList, UserProfile).
  • pages
    • Композиционный слой для сборки страниц из сущностей, фич и виджетов.
  • processes
    • Сложные сценарии, покрывающие несколько страниц (авторизация, регистрация, заказ)
  • app
    • Настройки, стили и провайдеры для всего приложения

Слайс (slices)

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

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

Слайс состоит из сегментов.

Сегменты (segments)

Это маленькие модули, главная задача которых разделить код внутри слайса по техническому назначению (UI, model, api, lib)

Итог

Плюсы

  • Позволяет найти однозначное место для любого кода
  • Легкая навигация по кодовой базе за счет стандартизации и единообразия
    • Код расположен согласно области влияния (слой), предметной области (слайс) и техническому назначению (сегмент
  • Контролируемое переиспользование логики
    • Каждый компонент имеет свое назначение и предсказуемый список зависимостей. Благодаря этому сохраняется баланс между соблюдением принципа DRY и возможностью адаптировать модуль под разные цели
  • Устойчивость к изменениям и рефакторингу
    • Один модуль не может использовать другой модуль, расположенный на том же слое или на слоях выше, что позволяет изолированно модифицировать приложение под новые требования без непредвиденных последствий
  • Ориентированность на потребности бизнеса и пользователей
    • Разбиение приложения по бизнес-доменам помогает глубже понимать, структурировать и находить фичи проекта
  • Существуют подходы для миграции на FSD
  • Масштабирование
  • Стандартизация
  • Наличие документации
  • ООП-синергия
    • Абстракция и полиморфизм за счет слоев
    • Инкапсуляция за счет public api
    • Наследование за счет слоев

Минусы

  • Высокий порог входа
  • Сложная система взаимосвязей
  • Большая вложенность сущностей
  • Сложное код-ревью

Подходит:

  • Для средних и больших проектов
  • Для команд любого размера