Правильный способ получения агрегатов в доменном дизайне

Question

В архитектуре DDD у меня есть суммарный корень Order и агрегат Product. Когда я хочу, чтобы добавить Product к определенному Order, я:

class Order 
{ 
    void AddProduct(Product p) 
    { 
    this.Products = p; 
    } 
} 

Затем OrderRepository сохраняется в оперативной памяти Order.Products colleciton к базе данных.

Мой вопрос: как я могу получить конкретное Product для определенного Order? Учитывая, что мы не должны вводить в репозитарии лиц, я не знаю, как гидрат Order.Products коллекции в памяти:

class Order 
{ 
    Product GetProduct(int productID) 
    { 
    return this.Products.Where(x => x.ProductID == productID); 
    } 
} 

Или это то, что принадлежит к OrderRepository?

Answer 1

class Order 
{ 
    void AddProduct(Product p) 
    { 
     this.Products = p; 
    } 
} 

Эта модель, вероятно, неверна.

(1) Если состояние Product должен удовлетворять бизнес-инвариант в Order, то Product должно быть юридическое лицо в совокупности порядка, но также не отдельный агрегат самостоятельно.

С другой стороны, если Order не нужно ничего знать о состоянии Product удовлетворить свои собственные инварианты, то набор продуктов не должен содержать продукты, но что-то еще (возможно Id<Product>)

Подсказка: есть ли смысл редактировать Product, изменив Order?

(2) Большинство дискуссий Order агрегатов прийти к выводу, что порядок держит коллекцию OrderItems (примечание: не агрегатов), где каждый OrderItem держит ссылку на агрегате продукта.

Тележки являются довольно распространенным примером случаем в дискуссии DDD

Answer 2

Я знаю, что этот вопрос имеет принятый ответ, но я выскажу свое мнение в любом случае :)

агрегатного Root (AR) никогда не должны обратитесь к другому AR. Он всегда использует либо только идентификатор связанного AR, либо объект Value (VO), который содержит идентификатор связанного AR вместе с некоторыми дополнительными дополнительными данными.

Интересная вещь об отношении Order ->Product заключается в том, что это типичное отношение «многие ко многим» в терминах базы данных. В мире баз данных можно было бы моделировать это, как правило, путем создания таблицы ассоциаций (или ссылок) с именем OrderProduct и добавления столбцов для любых данных, связанных с ассоциацией, таких как количество и цена. Однако, как-то таблица, которую мы все используем, называется OrderItem или OrderLine. Мы делаем это, потому что имеет смысл приблизить ассоциацию к порядку.

У меня есть блог вокруг этого, что до сих пор держит несколько верно: http://www.ebenroux.co.za/design/2009/09/08/many-to-many-aggregate-roots/

В мире DDD мы бы тогда не наши Order сохранить список ссылок на объекты в Product экземпляров. Вместо этого мы создадим VO под названием OrderItem, который содержит только ProductId, а также Quantity, Price и денормализованный ProductDescription, поскольку это описание может измениться после размещения заказа и, исторически, это изменит то, что было заказано, -нет.

Просто пищит для размышлений :)