Что такое Feature-Sliced Design

Feature-Sliced Design помогает вам ответить на простой вопрос: где должен жить код, чтобы его было безопасно менять через полгода. Вместо папок только по типам файлов, например components, hooks и utils, FSD предлагает смотреть на бизнес-смысл и уровень ответственности.

Хороший короткий ответ можно построить так:

FSD это архитектурная методология для frontend. Она раскладывает код по слоям и бизнес-слайсам, а зависимости разрешает только сверху вниз. Это помогает фичам меньше цепляться друг за друга, а команде проще понимать, где менять код и какие импорты опасны.

Такой ответ звучит сильнее, чем перечисление папок. Он показывает практическую цель подхода. На интервью у вас часто проверяют именно это: понимаете ли вы границы, а не просто помните названия директорий.

В актуальной FSD-структуре чаще всего говорят о слоях app, pages, widgets, features, entities и shared. Верхние слои собирают приложение и сценарии. Нижние дают более стабильные и переиспользуемые части.

Пример структуры может выглядеть так:

src/
  app/
    providers/
    router/
  pages/
    profile/
  widgets/
    profile-card/
  features/
    update-profile/
  entities/
    user/
  shared/
    ui/
    api/
    lib/

Практическое правило простое: features может использовать entities и shared, но shared не должен импортировать features. Если нижний слой начинает знать о верхнем, общий код становится зависимым от конкретного сценария. После этого любое изменение фичи может сломать места, которые вообще не должны были о ней знать.

В старых материалах по FSD можно встретить слой processes. Если вас спросят о нем, безопаснее сказать, что он встречается в старых проектах или в командах с длинными пользовательскими сценариями. В новых структурах его часто избегают и решают задачу через pages, widgets и features.

На собеседовании вас часто проверяют не определением, а практическим вопросом: куда вы положите новый код. Здесь лучше рассуждать от зависимостей и бизнес-смысла, а не от названия файла.

Не выносите код вниз только потому, что он понадобился два раза. Если кусок знает о конкретной форме, статусе модалки или бизнес-правиле одной фичи, ранний перенос в shared создаст ложную общность. Потом этот код начнут менять разные команды, и он станет источником регрессий.

Для UI-компонентов это особенно заметно. Общая кнопка в shared/ui не должна сама решать, что делать после логина или добавления в корзину. Ее задача проще: сохранить базовую доступность, нормальный текст, type для формы, фокус и возможность передать aria-label, если видимой подписи нет.

В FSD у слайса должен быть понятный внешний контракт. Обычно его собирают через index.ts. Внешний код импортирует только то, что слайс явно разрешил, и не лезет во внутренние папки.

Плохой вариант:

import { userStore } from "@/entities/user/model/private-store";
import { formatUserName } from "@/entities/user/lib/format-user-name";

Такой код связан с внутренней структурой entities/user. Если команда переименует файл или поменяет модель, сломаются внешние импорты. Еще хуже, если внешний компонент берет приватный store напрямую. Он может пропустить нормальную обработку loading, error и отмену запроса, а пользователь увидит старые данные или мигающий интерфейс.

Более безопасный вариант:

import { formatUserName, useUser } from "@/entities/user";

Здесь entities/user сам решает, что является публичным контрактом. Это не делает архитектуру идеальной автоматически, но снижает риск случайной зависимости от деталей реализации.

Главная польза FSD заметна в растущих продуктах. Когда команда добавляет новую фичу, вам проще понять, какие сущности уже есть, какие UI-блоки можно переиспользовать и где нельзя импортировать код. Конфликтов становится меньше, потому что изменения чаще остаются внутри одного слайса.

Еще один плюс виден на онбординге. Новому разработчику легче искать код по бизнес-сценарию: профиль пользователя, корзина, авторизация, оформление заказа. В структуре только по типам файлов тот же сценарий может быть размазан между десятками папок.

Но FSD не должен быть самоцелью. Если проект маленький, команда одна, а бизнес-логики мало, полная структура может добавить лишнюю сложность. В сильном ответе стоит признать этот trade-off и предложить применять методологию постепенно.

Если вас спрашивают про опыт внедрения, не обещайте переписать весь проект за один раз. Лучше показать спокойный план: выбрать проблемную область, договориться о границах, настроить правила импортов и только потом переносить остальные части.

На практике правила импортов стоит поддерживать не только договоренностями, но и инструментами. Команда может использовать ESLint-правила, алиасы, code review checklist и запрет глубоких импортов. Иначе архитектура быстро начинает зависеть от памяти конкретных разработчиков.