Если правильно делить по фичам то много маленьких какашек не принесут больших проблем

а кучу мелких?)

Есть мануалы понятные по ddd?

https://www.youtube.com/channel/UCGiT8Psj7xt5gezKUL8faNA понравился канал

Капец как долго и много, по порядку смотреть?

клева было бы как в матрице. нажал кнопку и все загрузилось и ты уже умеешь управлять вертолетом )

https://habr.com/ru/company/dododev/blog/489352/ еще и почитать попорядку

Это дает выделить домен, сделать из него конечный автомат(в широком смысле), и дергать API вашей доменки(один из UseCase) из разных точек входа в приложение (админка/пользовательский экшн/консьюмер/метод старого API), и все эти точки входа могут дергать один единственный UseCase.

Дальше уже вариативность и вкусовщина. UseCase может сам сверху работать с сущностью по анемичной модели, и следить за инвариантами системы, либо может делегировать это самой сущности, сделав ее "богатой", и заниматься только проверкой консистентности данных в приложении, для определения можно ли совершать эту команду, или нет с точки зрения бизнеса.

В итоге получаем четкие границы слоев, каждый из которых имеет свои ответственности, и позволяет переиспользовать код, который находится на более низких уровнях(более близкими к ядру приложения)
Можно погуглить картинку "Чистая архитектура", станет чуть понятнее

Ну и тестировать все это становится значительно проще.
Например, если мы используем богатую модель - то соблюдения инвариантов сущности можно проверить юнитами, и не трогать базу, UseCase можно покрывать интеграционными тестами без привязки к HTTP, а точки входа - своими функциональными тестами(в случае http - эмуляция запроса через kernel)

слои про дата флоу, про функциональную ответственность модули

мы разделяем дата флоу на слои (аутентификация, авторизация, трансформация какая, юзкейс, домен) для того что бы можно было лучше этим всем управлять. При этом слои сами по себе сущестуют больше в рантайме и не обязаны быть закреплены в коде. Разве что "отдельные элементы на разных уровнях в любом случае будут отдельными модулями". Но не обязательно иметь папку UseCases

цель наша - выстраивать высокоуровневую логику из более абстрактных примитивных блоков, emergence такой выходит

нет "богатой" модели, есть "насыщенная"

Да, согласен, тут слово "функциональную" было в широком смысле, например функция контроллера, как слоя представления - забрать данные из Request, переложить их на DTO, и передать в Handler

anemic vs rich это не про "бедную богатую". Метафора тут в том что если логика вытекает и размазывается это делает модель анемичной, как если ты уберешь кислород из крови. А то люди это воспринимают как две крайности из-за неверной инетпритации метафоры, а речь больше про "болею и норма"

на самом деле очень важный вопрос в этом всем - управление транзакциями и точки расширения. очень удобно когда один юзкейс - одна логическая транзакция. Могут быть варианты при котором одна бизнес операция это больше одной логической транзакции. Как в этом случае структурировать дата флоу - отдельный вопрос

ну мол, удобно когда у тебя юзкейс есть "зарегистрируй юзера" и по завершению транзакции твой юзкейс кидает доменный ивент "юзер зарегистрирован". Этот ивент может быть точкой расширения и продолжением флоу данных на которые могут быть подписаны другие подсистемы и запускать свои юзкейсы

1 и 3 пункты по сути про реюз кода
я вижу проблему в том, что идея разделения на слои никак не ограничивает этот реюз
Получается, что каждый юзкейс может зависеть от любого количества объектов из слоя домена и это выглядит как шаред стейт

это уже про контексты

при этом в каждом контексте мы можем свои правила вводить относительно дата флоу. В каком-то контексте все это надо, в другом можно просто делать инсерты из контроллера. Мы всеравно захотим сделать таких вариантов дата флоу не очень много - 2 может 3