И причем здесь доктрина?

ну сущность, она же в доменном слое она ведь может юзать нижележащие сервисы какие-нибудь, верно? мы такие рич модел придерживаемся, но не можем в методе сущности дернуть какой-то сервис, мы же в доктриновскую сущность не можем инжектить

еще пример, более конкретный у сущности (которая корневой агрегат) есть статусы, есть определенное действие, которое переводит в след статус, при условии что некоторые ее агрегаты в таком то состоянии.. как проверять эти агрегаты? передавать в метод репозитории, чтоб корневой агрегат достал эти агрегаты и проверил? там нет доктриновских one2many, у агрегата просто есть айдишник его агрегата

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

это доменная логика, уже точно не в контроллеры)

ну на те же сервисы, события, куда хош

тогда будет не rich.. понятное дело, не получится все доменную логику сосредоточить в агрегате а зачем тогда rich model вообще нужен? ну лично в моем случае

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

rich модел это не только состояние (как в анемик), но еще и поведение в том же месте где и состояние, за счет этого контроль над состоянием не размазан по всему приложению ровным слоем (если все владеют состоянием, то им не владеет никто), а лежит мирно в одном месте.

ну вот сущность имеет состояние, вот ее поведение пытаюсь запихнуть туда же) вроде правильно корневому агрегату нужно проверить свои агрегаты? при условии что агрегаты у нас доктриновские сущности, связи типа many2one и пр. - нет, агрегат имеет ссылку на свой корень корневой агрегат должен вытащить свои агрегаты, с помощью реп

Зачем ему проверять свои агрегаты? Они сами могут проверить себя. Инкапсуляция же.

ну допустим надо, никак по другому не понять, можно ли корневой агрегат перейти в след состоянии или в данном случае с проектированием что-то не то?

А, ну это проверка консистентности между агрегатами. Проверять тоже не надо. Верхний агрегат просто не позволит сделать так, что внутренние будут в разногласии. Тогда и проверять не придется

спасибо) навело на правильные мысли

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

в этом как раз заключалась проблема 😅 я как бы в курсе, что все действия - через корневой агрегат, но в какой-то момент протупил

сорри если надоедаю, но еще такой вопрос) и сорян что привожу пример с доками, но так думаю нагляднее будет есть документы, счета-фактуры и накладные, а есть такая штука как упд (эдакий контейнер для накладных и счетов-фактур, может включать в себя несколько и тех и других) получается, УПД - корневой агрегат, а счета-фактуры и накладные - его агрегаты прежде чем смогу совершить действие над корневым агрегатом, я должен перевести все его агрегаты в определенное состояние, делать это буду через корневой агрегат, тут все ок, просто/понятно НО счета-фактуры и накладные могут быть самостоятельными, хочется иметь возможность их юзать в т.ч. отдельно это разные контексты? та же счет-фактура у меня будет в двух видах, как корневой агрегат и как обычный? грубо говоря, в проекте это будет 2 разных сущности одного и того же, просто в зависимости от задачи юзаем то что нам надо? но ведь сущности идентичные, только лишь использование разное

А упд не может быть просто уникальным номером, который объединит эти доки в случае когда надо?