Если коротко, смысл Aggregate — работать с составной сущностью (иерархией сущностей), как с единым целым. Классический пример — заказ/строки заказа. В 99% случаев ваш код будет обрабатывать весь заказ целиком, т.е. агрегат будет включать в себя и Order и OrderDetails, корень агрегата — Order.
В вашем примере в агрегат можно запихнуть разве что пост+комментарии.
.
S>Если коротко, смысл Aggregate — работать с составной сущностью (иерархией сущностей), как с единым целым. Классический пример — заказ/строки заказа. В 99% случаев ваш код будет обрабатывать весь заказ целиком, т.е. агрегат будет включать в себя и Order и OrderDetails, корень агрегата — Order.
S>В вашем примере в агрегат можно запихнуть разве что пост+комментарии.
Мне кажется этого будет мало. User это просто данные о пользователе, пока User постит, модератор может удалить его блог, значит будет конкуренция.
Голова кругом. Я исходил из того, что агрегат — это сущность от которой можно пройти по связям до других сущностей(гарантировано). Если таких сущностей несколько, то у нас получается несколько агрегатов. В данном примере от User можно пройти весь граф объектов. Просто ни как не пойму где стыкуется ООП и DDD.
Здравствуйте, phenti, Вы писали:
S>>В вашем примере в агрегат можно запихнуть разве что пост+комментарии. P>Мне кажется этого будет мало. User это просто данные о пользователе, пока User постит, модератор может удалить его блог, значит будет конкуренция.
Во-первых, шансы на конфликт не зависят от того, относите вы пользователя к агрегату, или нет. Ваш сценарий ничем не отличается от попытки создать пост от имени несуществующего пользователя. Решаться он должен точно так же — выдачей пользователю сообщения "вас здесь не стояло".
Во-вторых пользователь (по крайней мере большинство) — это не часть блога, а самостоятельная сущность. Его конечно можно сделать корнем агрегата, который включает в себя блог пользователя, посты в этом блоге и комметарии (в том числе других пользователей) к постам. Результат получится громоздким и не будет покрывать ни один из типовых сценариев использования. И, как всегда при подходе "паттерны ради паттернов", достаточно одного простого требования — корпоративный блог с несколькими авторами — чтобы поломать всю абстрактную красоту.
P>Голова кругом. Я исходил из того, что агрегат — это сущность от которой можно пройти по связям до других сущностей(гарантировано). Если таких сущностей несколько, то у нас получается несколько агрегатов. В данном примере от User можно пройти весь граф объектов. Просто ни как не пойму где стыкуется ООП и DDD.
Агрегат не имеет никакого отношения к DDD, это просто способ компоновки объектов в стиле json/xml/иерархических СУБД. Зачем его протаскивать везде где можно и нельзя — это к фаулероведам.
Здравствуйте, gandjustas, Вы писали:
G>Здравствуйте, phenti, Вы писали:
P>>http://files.rsdn.ru/102993/classdiagram.PNG
P>>У меня получился, что один — User. Это правильно?
G>Нет, неправильно. Все неправильно.
G>Перед тем как рисовать схему данных нарисуй сценарии использования твоего приложения. После этого обычно глупых вопросов о схемах не возникает.
Это просто пример для того что бы вопрос задать, и все. Вот есть такое т.з. и его нужно сделать. Сценарии тут очевидны.
Здравствуйте, phenti, Вы писали:
G>>Перед тем как рисовать схему данных нарисуй сценарии использования твоего приложения. После этого обычно глупых вопросов о схемах не возникает.
P>Это просто пример для того что бы вопрос задать, и все.
Плохой пример. Это как начинать проектирование машины с выбора типа масла в двигателе.
P>Вот есть такое т.з. и его нужно сделать.
"Такое" в смысле в виде диаграммы? Выкинуть его надо.
P>Сценарии тут очевидны.
Да ладно?
1) Просмотреть последние посты друзей
2) Посмотреть последние посты второго круга + друзей
3) Посмотреть последние комменты в постах друзей
4) Просмотреть самые комментируемые посты второго круга + друзей
5) Просмотреть самые комментируемые друзьями посты
Таких сценариев можно напридумывать много, но далеко не все они будут реализованы, а только малая часть из них.
Какая часть — зависит от того что за приложение и для кого.
Если ты под сценариями понимаешь банальный crud, то просто используй access.
Это правильно?
Я исходил из того, что агрегат — это сущность от которой можно пройти по связям до других сущностей(гарантировано). Если таких сущностей несколько, то у нас получается несколько агрегатов. 
) — это не часть блога, а самостоятельная сущность. Его конечно можно сделать корнем агрегата, который включает в себя блог пользователя, посты в этом блоге и комметарии (в том числе других пользователей) к постам. Результат получится громоздким и не будет покрывать ни один из типовых сценариев использования. И, как всегда при подходе "паттерны ради паттернов", достаточно одного простого требования — корпоративный блог с несколькими авторами — чтобы поломать всю абстрактную красоту.
Мы уже победили, просто это еще не так заметно...
