Доступ к сущностям, которые не являются совокупным корнем

Я смотрю на DDD и у меня есть некоторые мысли. На торговом сайте у меня типичный Заказ.

public class Order
{
    public ICollection<OrderRow> OrderRows { get; set; }
    public ICollection<Payment> Payments { get; set; }
    ...
}

Платежи кажутся естественными для размещения в заказе. При оформлении заказа или работе с заказом оплата является частью заказа.

Но позже администратор захочет обрабатывать платежи отдельно. Например. в административном интерфейсе есть список платежей, которые необходимо обработать.

Как мне это сделать? Должны ли Платежи быть удалены из заказа и должны быть отдельным корневым агрегатом?


entity domain-driven-design aggregateroot
person Allrameest    schedule 31.01.2011    source источник

Ответы (3)


arrow_upward
2
arrow_downward

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

Так что в этом случае, да, при работе с Order вы должны предоставлять Payments как часть агрегата Order, но это не мешает вам также иметь выделенный PaymentRepository, который предоставляет Payment как совокупный корень.

person Dylan Beattie    schedule 31.01.2011
comment
Было бы очень неестественно, чтобы в большинстве доменов не было совпадений. - person quentin-starin; 01.02.2011

arrow_upward
0
arrow_downward

Я думаю, что объект «Платеж» не принадлежит агрегату «Заказ». Как вы написали, у вас есть функционал, который работает с платежами отдельно. Это означает, что платежи используются не только в контексте Заказа. Это означает, что Платежи не принадлежат совокупности Заказов :).
Однако возможно иметь свойство Payments в классе Order, даже если оно не является частью агрегата Order.

person Danil    schedule 31.01.2011

arrow_upward
0
arrow_downward

Если Платеж не может существовать без Заказа, то Платеж не является совокупным корнем.

Если это не совокупный корень, то загрузка соответствующих объектов Order из OrderRepository и работа с сущностями Payment внутри, по-видимому, имеют наибольшую целостность DDD.

person John    schedule 23.08.2012