В чем разница между FSD и другими архитектурами

Question

В чем разница между FSD и другими архитектурами

Тип вопроса: Архитектура Вероятность: 10% Категория: Frontend Разработчик

Ответ

FSD (Feature-Sliced Design) — это архитектура, которая делит приложение по бизнес-логике (фичам), а не по типам файлов (как MVC) или слоям (как Clean Architecture).

Отличия от других подходов:

Feature-based — структура строится вокруг фич (/cart, /profile), а не технических слоёв (/components, /api).
Изолированность — каждая фича независима и содержит свою логику, UI и API.
Масштабируемость — проще добавлять новые фичи без влияния на другие.

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

src/  
  features/  
    cart/      # Вся логика корзины  
      ui/  
      model/  
      api/  
    auth/      # Вся логика авторизации  
      ui/  
      model/

Плюсы:

Чёткое разделение зон ответственности.
Уменьшает связанность кода.

Минусы:

Требует дисциплины в организации импортов (нельзя импортировать фичи друг в друга напрямую).

Ответ 18+ 🔞

А, FSD, блядь! Ну это ж архитектура, которая делит всё не по каким-то там хуям-мухам вроде MVC, где у тебя модели, контроллеры и вьюхи свалены в кучу, а по бизнес-фичам, понимаешь? По смыслу, а не по типу файлов!

Представь, у тебя интернет-магазин. По старинке ты бы сделал папки components, pages, api. И в components у тебя лежали бы CartButton.tsx, AuthForm.tsx, ProductCard.tsx — всё в одну кучу, как говно в проруби. А потом приходит новый разработчик и хуй поймёт, что к чему относится.

А FSD говорит: «Да пошло это всё нахуй! Давай по-человечески!». И делит всё по фичам:

src/
  features/
    cart/              # Вся хуйня, связанная с корзиной — и кнопки, и логика, и запросы
      ui/              # Кнопки «Добавить», список товаров
      model/           # Стора, хуки, бизнес-логика корзины
      api/             # Запросы «получить корзину», «обновить корзину»
    auth/              # Вся авторизация, от формы входа до проверки токена
      ui/
      model/
      api/
    product/           # Карточки товаров, страница товара
      ui/
      model/
      api/

Каждая фича — как отдельная квартира. У неё свои стены, свой санузел, своя кухня. Живёт сама по себе и не лезет в соседскую квартиру через балкон с хуем. Изолированность — это ключ, ёпта!

И чем это, блядь, круто?

Масштабируемость, овердохуичная. Нужна новая фича «Избранное»? Хуяк — создал папку features/favorites/ и пилишь внутри всё, что надо. Не надо рыскать по всему проекту, не надо бояться, что сломаешь корзину.
Чёткое разделение. Новый чел приходит в проект, открывает структуру и сразу видит: «А, тут cart — значит, всё про корзину. Захожу туда и не вылезаю, пока не сделаю задачу». Никаких поисков по всему src.
Связанность кода уменьшается. Фича cart не должна напрямую импортировать что-то из фичи auth. Общение — через публичные API (типа общие хуки, абстракции). Это чтобы не получилось спагетти, где всё держится на соплях и надежде.

Но и минусы, ядрёна вошь, тоже есть:

Дисциплина, блядь, нужна железная. Нельзя просто так взять и импортировать компонент из features/auth/ui прямо в features/cart/ui. Нарушишь изоляцию — получишь ебаный циклический импорт и проект, который собирается дольше, чем я дохожу до работы с похмелья. Нужно чётко соблюдать правила импортов (снизу вверх, публичные API).
Может быть избыточно для маленьких проектов. Если ты делаешь сайт-визитку на три страницы, то заморачиваться с FSD — это как из пушки по воробьям: оверкилл, блядь.

Короче, суть: FSD — это когда ты организуешь код не вокруг технических деталей (компоненты, страницы), а вокруг бизнес-возможностей (корзина, профиль, товары). Это делает код понятнее и устойчивее к росту. Но требует, чтобы вся команда не была распиздяями и соблюдала договорённости. А то получится «архитектура на коленке», и потом все будут орать «да кто так строил, пиздец!».