Агрегированные корни против агрегатов в иерархической системе

Question

Я много исследовал DDD и немного спотыкался о концепции Агрегаты против Совокупных корней.

Скажем, я пытаюсь смоделировать космическую игру, которая существует в строгая иерархия, с сущностью Sector, которая охватывает все, что в ней содержится. Он может иметь коллекцию PlanetarySystem, каждая из которых может иметь коллекцию Star, звезды могут иметь коллекцию Planet, которые сами могут иметь коллекцию Moon

Я хочу Все эти объекты либо связаны с этим Sector, расположенным в иерархии, но и с сектором. Каждый элемент может иметь связь 0 или 1 с объектом в иерархии над ним ... плавающим в эфире, если это необходимо. Я хочу иметь возможность удалить Planet без удаления всех Moon сущностей, которые у него есть, но это можно сделать по желанию.

Неправильно ли я думать, что каждый из них должен быть их собственным Совокупным Root в этом сценарии со ссылками на совокупные Root экземпляры, которые они содержат? Или Sector должен быть фактическим Агрегатом Root, управляющим всем как объектом на вершине иерархии?

Answer 1

Агрегат root никогда не должен содержать ссылку на другой агрегат root. Вы должны использовать либо идентификатор для ссылки на связанный агрегат, либо объект значения, содержащий идентификатор и некоторые другие соответствующие данные.

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

Я считаю, что иерархия должна работать в однонаправленном режиме в том, что касается домена. Если вам нужно запрашивать элементы более низкого уровня на основе содержимого более высокого уровня, то вам либо нужны объединения, либо необходимо денормализовать соответствующие идентификаторы / данные более высокого уровня в элементы более низкого уровня.

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

Answer 2

Помните, что что-то может быть Агрегатом в одном случае использования и Агрегатом Root в другом. Если ваш вариант использования AddPlanetarySystemToSector, то Sector - это ваш агрегат Root. Если ваш вариант использования AddMoonToPl anet, то Pl anet - это AR.

Разница в том, что AR не следует сохранять, если только он и все принадлежащие ему агрегаты не удовлетворяют всем бизнес-правилам. Чем выше уровень AR, тем больше бизнес-правил вы должны проверить и удовлетворить. Поэтому ваши варианты использования должны быть как можно более точными c и нацеливаться на соответствующий AR.

Если это создает проблемы, обходной путь должен иметь собственные объекты значений AR вместо агрегатов. Таким образом, Сектор будет владеть PlanetarySystemVOs. Если Сектору необходимо изменить PlanetarySystem, он может запустить сценарий использования PlanetarySystem, который выполняет соответствующее действие.