Здравствуйте, phenti, Вы писали:

S>>В вашем примере в агрегат можно запихнуть разве что пост+комментарии.
P>Мне кажется этого будет мало. User это просто данные о пользователе, пока User постит, модератор может удалить его блог, значит будет конкуренция.

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

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

P>Голова кругом. Я исходил из того, что агрегат — это сущность от которой можно пройти по связям до других сущностей(гарантировано). Если таких сущностей несколько, то у нас получается несколько агрегатов. В данном примере от User можно пройти весь граф объектов. Просто ни как не пойму где стыкуется ООП и DDD.
Агрегат не имеет никакого отношения к DDD, это просто способ компоновки объектов в стиле json/xml/иерархических СУБД. Зачем его протаскивать везде где можно и нельзя — это к фаулероведам.