Какие были трудности с FSD

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

Первая засада — это, блядь, границы слоёв. Вот сидит у тебя, допустим, сущность product. Казалось бы, всё ясно: название, цена, артикул — лежит в entities/product. А потом бац — тебе надо отобразить карточку товара в каталоге, и там уже скидка, рейтинг, кнопка «в корзину». И ты такой: «Так, стоп, а это уже features/product-card или всё ещё entities?». И начинается, ёпта, философский спор на три часа: «А по моему мнению, рейтинг — это фича!», «А я считаю, что это часть сущности!». В общем, чтобы не было мордобоя, нужно сразу чётко договориться, где чей хуй висит. Иначе проект превратится в бардак, где всё свалено в одну кучу, как в шкафу у подростка.

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

Третья штука — роутинг. В классическом FSD про маршруты нихуя не сказано. Где их хранить? В каждой фиче? В отдельном слое app? А если у тебя вложенные маршруты? Можно так заплутать, что потом сам черт ногу сломит. Нужно сразу, как мантру, принять правило: например, все маршруты описываем в app/routing и не выёбываемся.

Ну и четвёртый пункт — тестирование. Поскольку каждая фича у нас — это такая независимая вселенная, то чтобы её потестить изолированно, нужно накрутить мокапов на все её зависимости. Это, конечно, овердохуища работы. Зато, когда всё работает, чувствуешь себя богом тестирования, который может сломать что угодно, и ничего не развалится.

Вот смотри, как выглядит эта красота в коде, если сделать по уму:

src/
  features/
    cart/          # Вся хуйня с корзиной: добавление, удаление, пересчёт
    product/       # Карточка товара, галерея, рекомендации — всё, что видит юзер
  entities/
    user/          # Данные пользователя, модель, апи-запросы
    product/       # Базовая модель товара, без прикрас
  shared/
    ui/            # Кнопки, инпуты, карточки — то, что тыкается везде
    lib/           # Утилиты, хелперы, конфиги — скелет проекта

И главные правила, чтобы не сойти с ума:

1. Документируй границы, блядь! Напиши в README, что в entities лежат голые данные, а в features — уже причёсанные для юзера. И все пусть это читают, а не тыкают пальцем в небо.
2. shared — твой лучший друг. Всё, что используется больше чем в одном месте, тащи сюда. Но без фанатизма, а то превратишь его в свалку.
3. Ревью кода — святое. Иначе какой-то умник загонит бизнес-логику прямо в shared/ui/Button.tsx, и потом полгода будешь разгребать. Нужно ловить такие моменты на подлёте.

В общем, архитектура эта — как острый нож: в умелых руках — инструмент, в кривых — себе же хуже сделаешь. Думай головой, не ленись обсуждать с командой, и всё будет пучком. А если нет — ну, что ж, значит, не судьба, будем по-старинке, в одном файле на десять тысяч строк кодить.