Весной стартует сезон найма, успей отхватить свой оффер!

FSD (Feature-Sliced Design) архитектура

Feature-Sliced Design (FSD) — это архитектурная методология для frontend-приложений. Проще говоря, это свод правил и соглашений по организации кода. Главная цель методологии — сделать проект понятным и структурированным, в условиях регулярного изменения требований бизнеса.

Основные концепции FSD

  1. Разделение по слоям (slices)

    • App: настройки приложения, глобальные провайдеры, роутинг.
    • Processes: крупные бизнес-процессы, которые затрагивают всё приложение (например, онбординг пользователя или платёжный процесс).
    • Pages: страницы приложения с конкретным UI, маршрутами и контейнерами.
    • Features: отдельные пользовательские фичи (например, «добавление товара в корзину», «авторизация»).
    • Entities: модули с описанием и логикой «сущностей» предметной области (User, Product, Order и т.д.).
    • Shared: общие библиотеки, утилиты, переиспользуемые компоненты (кнопки, иконки, функции валидации).
  2. Группировка кода по фичам
    Вместо того чтобы хранить все компоненты в одной папке components/, все стили в styles/ и т.д., FSD предлагает хранить весь код, относящийся к функционалу (UI-компоненты, логику, стили, тесты), в одной фиче. Это повышает когезию (целостность) и упрощает поиск нужных файлов.

  3. Чёткие границы ответственности
    Каждый слой отвечает за свой набор задач. Например, изменения в фиче обычно не затрагивают другие фичи, поскольку общие инструменты живут в shared/, а глобальные настройки — в app/ или processes/.

Преимущества FSD

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

  2. Упрощение сопровождения
    Если нужно разобраться в конкретной фиче или внести правки, разработчик видит всю логику фичи — от компонентов до стилей — в одном месте.

  3. Модулируемость
    Легко подключать или отключать конкретные фичи, перенести их в другой проект или сделать отдельным пакетом.

  4. Минимизация конфликтов в команде
    Разработчики могут параллельно вести работу над разными фичами, не мешая друг другу.

Пример структуры

В данных примерах:

  • app/ содержит глобальную инициализацию и конфигурацию приложения.
  • processes/ включает в себя «длинные» бизнес-процессы (например, многошаговые сценарии).
  • pages/ — отдельные страницы (роуты).
  • features/ — набор фич (каждая фича содержит всё нужное для своей работы: UI, бизнес-логику и т. д.).
  • entities/ — описание моделей (User, Product и др.) и их поведение.
  • shared/ — переиспользуемые компоненты, утилиты и конфигурации.

Рекомендации по применению

  • Начинайте с малого: не нужно сразу насильно вводить все слои, если у вас маленькое приложение. Добавляйте слои по мере роста проекта.
  • Чётко определяйте границы фич: фича должна решать одну конкретную задачу (например, «управление профилем пользователя» или «добавление товара в корзину»).
  • Используйте именование: если структура проекта становится сложной, придерживайтесь единых правил именования директорий и файлов, чтобы не запутаться.
  • Следуйте принципам DRY, YAGNI и KISS: FSD — это лишь схема организации кода. Она не отменяет базовых принципов написания чистого кода и продуманной архитектуры.

Источник

Подробнее про Feature-Sliced Design можно почитать здесь.