Может ли агрегат Root быть дочерним по отношению к сущности в DDD (доменно-управляемый дизайн)?

Question

Я унаследовал проект, использующий архитектуру доменного управления, и очень мало знаю о DDD. Я читал много блогов и литературы по этому вопросу. В настоящее время у меня есть 3 модели предметной области со следующим отношением графа: Родитель -> имеет много детей -> имеет много детей GrandChildren. Я использую EF Core 2.1, чтобы установить sh связь и сохранить данные в базе данных.

• Родитель имеет PK
• Дочерняя модель имеет FK to Parent
• Модель внука имеет FK для ребенка

Мой вопрос: Можно ли иметь следующие отношения для DDD

Проблема : Я не могу сохранить нового внука для существующего потомка.

Родитель как совокупность Root ==> Дочерний как сущность ==> GrandChil как совокупный Root

Я могу сохранить «потомок» через существующего «родителя», используя parent.add (потомок), и данные сохранятся в базе данных без каких-либо проблем.

Для «внука» я использую аналогичный подход:

1. Получить существующего родителя, а затем получить существующего дочернего элемента

2. Добавить внука к существующему дочернему элементу [child.addNewGrandChild ( new_grand_child)] * ​​1033 *

3. UnitOfWork.Complete [ здесь выдается исключение но я просто не могу захватить исключение, используя Try / Catch ]

Answer 1

Я решил свою проблему, преобразовав класс Grandchild в Entity вместо Aggregate Root. Как только я это сделал, все заработало. Другими словами, я смог сохранить данные через Родителя.

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

Answer 2

Поймите, что правильное выполнение DDD не налагает каких-либо ограничений на базу данных, и наоборот, база данных не будет налагать какие-либо ограничения на DDD или ее 'модели.

Внуки не должны быть совокупными корнями. Когда у вас есть что-то подобное, более чем вероятно, что вы пропускаете контекст в своем домене и / или границы определены неправильно.

Имейте в виду, что понятия отношений DDD не имеют ничего общего делать с базой данных и ФК. Что касается DDD, то база данных моделируется как зависимость непрозрачного хранилища для всей системы.