но не объекты

это ООП этим определением кишит, а не ДДД

мы моделируем ВЗАИМОДЕЙСТВИЯ а не "объекты"

все понятно, значит мы читали разные книги)

сейчас конечно не смогу найти цитату и сказать на какой странице, но поищу)

моделирование на сущностях приведет к логическому кохижену и высокой связанности

а ООП противопоставляется DDD?

В какой-то книге точно читал, в какой именно, по ООП или DDD сейчас сходу не вспомню.

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

это те же люди у которых классы студентов наследуются от классов человека

как раз моделирование на всяких сервисах (когда не умеют делить логику на отдельные объекты) приводит к такому

по другому сформулирую - "большие" сущности которые фигурируют в обсуждении с бизнесом (продукты, карзина, склад, шо там еще придумать можно)

это верно

Не знаю, с какими проектами в обычной работе вы работаете

Я как раз вижу говнокод, где сущности симвони - чисто объекты с данными, а логику пихают во всякие сервисы, при чем все в одно - нужно что-то делать с юзером - создается UserSerivce и все пихается в него

у тебя юниты это тоже такие большие сущности ибо не обслуживают конкретные бизнес правила

ну вот а теперь представь что есть еще третий вариант)

с этим согласен полностью

как развиваются разработчики:

- анемия + сервисы (процедуры)
- о давайте логику из сервисов в сущности запихнем без пересмотра того как мы сущности выделяем (часто те же процедуры только сложно)
- functional cohesion и просветление (больше похоже на эктор модел)

на втором этапе многие отваливаются в сторону первого 🙂

ну и не мудрено ибо пиздец же на больших проектах

потом пишут статьи что это солид нарушает и только анемия только хардкор

Кстати, версия боя, что вы смотрите - это переписанная (не до конца еще) версия 2017 года

Вот там хардкор - статика, массивы, отсутствие тестов и т.д. Все как в Yii2 xD

По сравнению со старым кодом - новый просто божественный (имхо конечно)

В общем, сделал вывод, что нужно устраиваться в более крутые команды, где знают про DDD, и где его можно будет обсудить, на конкретных книгах, примерах и т.д. Часто в компаниях не до этого вообще.