DDD Какой корневой агрегатный корень?

Имеет смысл множество примеров, таких как порядок и строки заказа, например:

Order - AR, содержащий OrderLines Customer - AR, содержащий Orders.

Вопрос в том, что такое AR, содержащее Customer? Думаю, это может быть что-то вроде «магазин».

So, shop.AddCustomer(customer)...

но как попасть в магазин? Если это AR (объект), у него есть идентификатор, поэтому shop.GetById(shopId). Если у меня только один магазин, как это работает с упорством?

Стоит ли стол (магазины) с одной линией? Shop - это объект в памяти с набором Customers?


domain-driven-design aggregateroot
person Bart Calixto    schedule 22.12.2015    source источник

Ответы (1)


arrow_upward
6
arrow_downward

Вы ошиблись здесь. Агрегаты не содержат других агрегатов! Они могут ссылаться на них только по идентификатору.

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

Customer, с другой стороны, будет ссылаться на Orders только по идентификатору, если это отдельный агрегат.

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

person theDmi    schedule 23.12.2015
comment
В каком контексте вы создаете клиентов? - person Bart Calixto; 23.12.2015
comment
@BartCalixto Вы либо создаете его экземпляр напрямую, либо используете фабрику (если конструкция нетривиальна). Затем вы передаете вновь созданный агрегат в репозиторий, например customerRepo.create(theNewCustomer) - person theDmi; 23.12.2015
comment
@theDmi Когда вы говорите, что клиент будет ссылаться на заказы только по идентификатору (например, $ customer- ›getOrders ()), будет ли getOrders () возвращать только массив идентификаторов или будет возвращен объект заказов? - person Jonathan; 23.12.2015
comment
@Jonathan Это логическое следствие правильного совокупного дизайна. Он вернет только список идентификаторов. Если это серьезная проблема для определенного домена, то, вероятно, совокупные границы неверны. Разделение здесь - всего лишь пример. - person theDmi; 23.12.2015
comment
Я бы сказал, что Order будет ссылаться на CustomerId, а не наоборот, если не нужно применять специальный инвариант, такой как максимальное количество активных заказов ... и даже тогда ... - person plalx; 23.12.2015
comment
@theDmi Хорошо, это имеет смысл, но вот еще один пример, который меня смущает, допустим, у нас есть два общих корня - Автор и Книга. Возвращает ли $ author- ›get books () массив идентификаторов книг или объект BookAggregate, содержащий массив идентификаторов книг? - person Jonathan; 23.12.2015
comment
@Jonathan Это снова тот же пример! Агрегаты никогда не должны иметь навигационных связей с другими агрегатами, как бы вы ни крутили примеры. - person theDmi; 23.12.2015
comment
@ Джонатан, я думаю, ты имел в виду $bookRepo->getAllByAuthorId($author->authorId). - person inf3rno; 09.01.2016