Ну и завершая тему DDD (готов уворачиваться от помидоров) — ни в одной рекламной статье вам не расскажут про "DDD трилемму" — аналог CAP-теоремы для моделирования доменов.

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

Дело в том, что из трёх китов: изоляции доменной логики, чистоты модели и производительности можно выбрать, как обычно, только два пункта.

В реальной жизни у вас либо бизнес-логика оказывается размазана по уровням (что-то контролируется в модели, что-то — в контроллере, что-то вообще в БД), либо модель должна ходить в базу / в глубинные слои инфраструктуры, соответственно — начинает зависеть от реализации, либо всё красиво и абстрактно, но нещадно тормозит.

Вот ключевая статья на эту тему от Владимира Хорикова https://enterprisecraftsmanship.com/posts/domain-model-purity-completeness/ + преза на русском.

Там простой пример: проверка уникальности email'а при регистрации пользователя. Как его делать? То ли передать с уровня домена в контроллер (и там сначала проверить существование пользователя с таким email), то ли прямо из модели пользователя сходить в хранилище поискать email'ы, то ли поднимать всех пользователей из хранилища на уровень домена, и отдавать модели пользователя (сожрет всю память).

Ну и вот, выбирайте, как хотите. И так, и так, и так будет криво, вопрос — с какой кривизной вы готовы столкнуться?

Это, в общем, следствие старого Закона дырявых абстракций Джоела Спольски: все нетривиальные абстракции дырявы.

И DDD тут тоже не является серебряной пулей. Собственно, претензии к адептам примерно те же, что и к инфобизнесменам — не в том дело, что приемы какие-то неправильные, дело в том, что нельзя создавать впечатление, что DDD решит все проблемы с целостностью и изолированностью изменений. Не решит. Всё равно придётся выбирать плохое из худшего.