Должен ли я избегать использования совокупных корней?

Question

ПРОБЛЕМА

Есть четыре лица:

class Product : Entity<Product> { 
    public virtual String Title { get; set; } 
    public virtual Category Category { get; set; } 
    public virtual Vendor Vendor { get; set; } 
} 

class Category : Entity<Category> { /* properties */ } 
class Vendor : Entity<Vendor> { /* properties */ } 

Ни один из этих четырех определяются как компоненты, и я не знаю, какой из них следует использовать (отметьте его IAggregateRoot интерфейс), как совокупный корень.

Мне нужно, чтобы легко получить доступ списки поставщиков, категории, чтобы показать их на странице при создании нового продукта.

Тогда должно появиться три экземпляра Repository в соответствии с этими объектами.

ASIDE

Я видел несколько крупномасштабных проектов. Они массово используют списки независимых объектов, таких как Vendor, State, TechnicalOptions. Я думаю, что логично разрабатывать вещи с совокупными корнями, но я не знаю, подходят ли там принципы DDD.

Answer 1

Они выглядят как различные агрегаты, и это может быть подтверждено, используя правило каскадного удаления:

верховенстве каскадного удаления иногда упоминается как хороший способ сказать, если у вас есть группа лиц или VO, которые должны быть Aggregate - если родитель был удален, все остальные части этого Агрегата ниже будут также удалены. Итак, если не имеет смысла, что родитель, удаляемый, также удалит всех детей, тогда у вас нет агрегата, у вас просто хорошая старомодная ссылка.

В вашем случае, если у вас есть продукт, если вы удалите его, вы не хотите, чтобы каскадные удаляли все связанные категории, поскольку они могут быть связаны с другими Продуктами (вы можете применить эти правила к другим объектам). Таким образом, у вас, вероятно, будет один репозиторий для каждого из них

Answer 2

У вас не должно быть одного AR-ссылки экземпляра другого. Скорее ссылку по ID или использовать объект Value.

Тогда постарайтесь не запрашивать вашу модель домена, так как это приводит к некоторым ленивым и другим неприятным проектам. Скорее создайте тонкий слой запроса, чтобы вернуть нужные вам данные. Возможно, вы даже захотите денормализовать некоторые данные для слоя запроса, чтобы повысить производительность.