Агрегировать объекты в DDD

Question

Могу ли я использовать тот же агрегатный класс, что и член других классов? И если да, то будет ли класс, содержащий агрегат, обеспечивать доступ и т. Д. К этому?

Допустим, у вас есть класс пользователя. Затем класс с именем LogBook и, наконец, класс с именем Log / Post (что-то в этом ряду). LogBook будет агрегированным корнем для класса Log / Post, а User будет общей агрегацией в моем примере. Теперь, будет ли класс User содержать методы для добавления записей журнала и т. Д.? Вы бы сделали один метод в классе User, который вызывает класс LogBook, у которого есть метод, который выполняет всю логику для фактического добавления журнала.

Или совокупность ВСЕГДА на вершине иерархии? Нет вложенности.

Answer 1

Вот хорошее определение Агрегата:

Определение: кластер связанных объектов, которые рассматриваются как единое целое для целей изменения данных.Внешние ссылки ограничены одним членом Агрегата, обозначенным как корень.Набор правил согласованности применяется в пределах Агрегата.Проблема: Трудно гарантировать согласованность изменений объектов в модели со сложными ассоциациями.Необходимо поддерживать инварианты, которые применяются к тесно связанным группам объектов, а не только к отдельным объектам.Тем не менее, осторожные схемы блокировки приводят к тому, что несколько пользователей бесполезно мешают друг другу и делают систему непригодной для использования.[DDD, с.126] ​​Решение: кластеризовать сущности и объекты-ценности в агрегаты и определить границы вокруг каждого из них.Выберите одну сущность, которая будет корнем каждого агрегата, и контролируйте весь доступ к объектам внутри границы через корень.Разрешить внешним объектам хранить ссылки только на root.Временные ссылки на внутренние элементы могут быть переданы для использования только в рамках одной операции.Поскольку корень контролирует доступ, его нельзя игнорировать из-за изменений во внутренних органах.Такое расположение делает практичным применение всех инвариантов для объектов в Агрегате и для Агрегата в целом при любом изменении состояния.[DDD, с.129]

Не думаю, что вы хотите, чтобы класс User достигал агрегированных объектов LogBook, не пройдя через класс LogBook.Тем не менее, доступ к журналу от пользователя выглядит нормально.

Answer 2

Я думаю, что внутренности агрегата могут содержать ссылки на корень других агрегатов.Но каждый агрегат отвечает за соблюдение своих собственных границ.Ничто не мешает другим объектам полностью получить доступ к «ссылочному» агрегату за пределами первого - т.е. я не думаю, что вложение или владение подразумевается только потому, что один агрегат ссылается на другой.Похоже, что LogBook подойдет лучше как совокупность, контролирующая доступ к сообщениям.Попытка включить это в более крупную совокупность пользователей кажется неловким фактором ответственности.