Как определять, какие компоненты и логику делить на слои при внедрении FSD

Что проверяют

Знаете ли вы Feature-Sliced Design по существу или только названия папок. Интервьюеру важно, как вы решаете спорные случаи: фича это или сущность, когда код переезжает в shared. Следом часто спрашивают, как вы не даёте слоям импортировать друг друга в обход правил.

Как отвечать

Коротко напомните устройство. Слои сверху вниз: app, pages, widgets, features, entities, shared, слой processes объявлен устаревшим. Модуль импортирует только из слоёв ниже себя, слайсы одного слоя друг друга не импортируют. Внутри слайса сегменты ui, model, api, lib, config, а наружу виден только публичный API через index.ts.

Затем дайте критерии, по которым раскладываете код:

• entities: существительные предметной области. Пользователь, товар, заказ: их модель, запросы к API и базовое отображение вроде ProductCard;
• features: действие пользователя, которое несёт ценность. Добавить в корзину, войти по телефону, оставить отзыв. Проверочный вопрос: можно ли назвать это глаголом;
• widgets: крупный самостоятельный блок из фич и сущностей. Шапка, лента товаров с фильтрами;
• pages: композиция виджетов под конкретный маршрут;
• shared: всё, что не знает о бизнесе. UI-кит, HTTP-клиент, утилиты, конфиг.

Важная оговорка из свежей редакции методологии: не выносить код заранее. Пока логика нужна одной странице, она живёт в этой странице, а в features и entities переезжает, когда появился второй потребитель. Правила проверяют официальным линтером Steiger или ограничениями импортов в ESLint.

Где спотыкаются

Делают фичей каждую кнопку. Через месяц в features сотня слайсов по одному компоненту, и ориентироваться в проекте труднее, чем до FSD.

Сваливают в shared всё, что используется больше одного раза, включая бизнес-логику. Слой превращается в свалку, которую боятся трогать.

Путают FSD с классической трёхслойкой «представление, логика, данные». Слои FSD делят код по уровню бизнес-ответственности, а технические роли живут уровнем ниже, в сегментах.