⚔️ "Feature Sliced" vs "Clean Architecture"
Вот уже год слежу за этим противостоянием. И могу подвести свои промежуточные выводы.

Года четыре назад меня сильно вдохновил доклад про "Clean Architecture" (я тут спецом взял в кавычки, чтобы было понятно, что имеется в виду именно структура проекта, а не подход) от Джейсона Тейлора.

Мне понравилось, что была предложена структура, по которой можно быстро клепать новые приложения, и, при необходимости, так же быстро понимать чужие, написанные в этом стиле.

За последний год-два "Clean Architecture" начали много ругать. Даже мой любимый Дерек Комартен высказался против (вот же сука! но все по делу!). Основные тезисы такие:
1️⃣ Неудобные хэндлеры в медиатре, что ведет к сильной неявности вызовов.
2️⃣ Размазывание логики по слоям, что ведет к открыванию кучи файлов во время разработки новой фичи или редактирования старой. (да, вот это хуево, тут никаких споров.)

😭 Честно признаюсь, мне было удобно работать c "Clean Architecture" . У нас в компании довольно много репозиториев написано с оглядкой на эту структуру проекта. И я вообще топил за то, чтобы как можно больше сервисов было написано в этом стиле. Так было бы удобнее ходить между проектами.

Но вот недавно поработал с парочкой репозиториев сделанных в "Feature Sliced" стиле. И могу сказать, что, видимо, это действительно более удачный подход.

Я сделал две очень похожих фичи и так и эдак. И в Feature Sliced варианте получилось все гораздо быстрее и понятнее. Минус в том, что порой приходилось копировать контракты для входных и выходных данных, но не сказал бы что это было напряжно.

У "Clean Architecture" все же есть один плюс. Говорят его относительно легко постепенно перевести в Feature Sliced. Буду короче пробовать на пет-проектах на своих. Хотя я все еще считаю, что для своего времени Clean Architecture заебись и что медиатр топчик.

🅰️ Так что хуярьте все по Feature Sliced. Хотя бы свои пет-проекты.

Ну и это... RIP "Clean Architecture" 🪦