Сначала — боль
Начинается любой проект одинаково: чистая папка, аромат свежего create-app и амбиции «в этот раз всё будет красиво». Через полгода у UserCard роман с ProductList, Cart ревнует, сборка падает на циклических зависимостях, а новый SuperButton смотрит на вас как кот на пылесос — и куда его теперь?
Узнаёте? Это не «вам показалось». Это натуральный хаос роста без архитектуры.
Что такое FSD и почему он поселился у меня в голове
Feature‑Sliced Design — это не про то, «как красиво раскладывать папки». Это про взрослую дисциплину. Слои и правила, которые позволяют проекту расти, а вам — спать.
С тех пор как я перевёл на FSD первый крупный фронтенд, я использую его везде. Потому что он снимает главный вопрос: «где жить этому коду?»
Слои простым языком
- shared — общий инструментальный ящик: UI‑примитивы, утилиты, клиенты
- entities — предметные сущности:
User,Product,Order - features — пользовательские сценарии: «войти», «добавить в корзину»
- widgets — крупные блоки из фич и сущностей:
Header,ProductGrid - pages — страницы целиком
- app — инфраструктура: провайдеры, роутинг, темы
Золотое правило: импортируем сверху вниз. Обратный импорт — красная карточка и «идём переписывать».
Контекст эпохи
2018–2025 — бурный рост сложности фронтенда: микрофронтенды, дизайн‑системы, десятки фич‑тимов в одном репо. «Папка components» перестала вытягивать масштаб. FSD — ответ на бизнес‑проблемы, не только инженерные:
- Снижение стоимости изменения: меньше скрытых связей → дешевле дорабатывать
- Предсказуемый онбординг: новички быстрее становятся продуктивными
- Управляемые риски релизов: границы слоёв ограничивают радиус поломок
- Лучше метрики: понятные ownership‑зоны и accountability
Почему FSD работает в реальной жизни
Предсказуемость
Любая задача раскладывается на «куда положить». Примитив — в shared/ui, бизнес‑сущность — в entities, действие — в features, композиция — в widgets. Не надо гадать.
Переиспользование без боли
Нижние слои не знают о верхних. Кнопка из shared не тянет за собой пол‑приложения. Удивительно, сколько нервных клеток экономит это правило.
Масштабирование команды
Новичок за день понимает планировку проекта. Код‑ревью ускоряется, потому что спорить «куда класть» теперь не надо — правила уже ответили.
Типовые грабли (и как мы их обошли)
«Всё пихаем в features»
Хочется — понятно. Но через месяц features превращается в свалку. Не ленимся: всё, что про данные и модели — в entities, всё переиспользуемое без бизнес‑контекста — в shared.
«Ой, у нас бизнес‑логика в shared»
Нет. shared — стерильная зона. Любая доменная логика — в сущностях и фичах. Пусть shared остаётся «отвёрткой», а не «полприбора».
«Слои есть, правил нет»
Если не следить за импортами — FSD превращается в декорацию. Включите линт‑правила и договоритесь в команде, что будет считаться нарушением. Главное — не буквальность, а дисциплина.
Мини‑FSD для старта
На маленьких проектах не надо устраивать архитектурный парад. Достаточно shared → features → pages. Перерастёте — добавите entities и widgets без боли.
FSD — это не религия. Это практичный каркас. Возьмите базу, подстройте под себя и не усложняйте там, где можно не усложнять.
Когда FSD не нужен (и это нормально)
- Лендинги на пару экранов
- Прототипы на неделю
- Один разработчик и короткий жизненный цикл
Итог
FSD даёт фронтенду предсказуемость, а команде — общий язык. Он не решит все проблемы, но спасёт от самых дорогих: хаоса импортов, утёкших абстракций и развороченных релизов.
Если кратко: FSD — это каркас, который экономит время, нервы и деньги. И да, он действительно работает, когда проект перестаёт быть игрушкой.
См. также
- Slot‑Me — платформа бронирования встреч — фронт на FSD в проде
- PassWave — генератор паролей — FSD даже в небольшом продукте
