Совокупные корни. Как далеко заходит кроличья нора

Question

Я пытаюсь использовать шаблон Repository для моего текущего проекта, и в настоящее время я пытаюсь смоделировать домен и найти совокупные корни.

Я читал правило «Каскадное удаление», которое гласит, что если нет смысла удалять элемент при удалении корня, то он не должен быть частью корня.

Я буду использовать полицейский инцидент в качестве примера: -

Инцидент (Совокупный корень) - может содержать следственные органы, записи, сделанные каждым сотрудником. Он также может содержать подозреваемых со списком дат, которые были опрошены. Были ли сняты кадры видеонаблюдения для этого инцидента? Журнал каждого просмотра CCTV и кем? Были сделаны копии с видеонаблюдения для доказательств / суда и т. Д.

Кажется, что IncidentAggregate может стать огромным, поскольку кажется, что все зависит от этого инцидента.

У меня двоякий вопрос: насколько должен справляться совокупный корень, и являются ли корни внутри корней хорошей идеей?

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

Answer 1

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

Чтобы использовать вашу аналогию. Предполагается, что отчет является частью только одного агрегата инцидентов и будет удален вместе с агрегатом. Ни один другой агрегат не получит прямого доступа к этим отчетам.

Однако совокупность инцидентов будет ссылаться на агрегаты, представляющие офицеров и подозреваемых, а также записи журналов наблюдения CCTV.

Answer 2

Агрегат - это группа объектов с одинаковым жизненным циклом.

Если вы удалили инцидент, вы бы хотели удалить следователя? Нет, если бы ты это сделал, у тебя скоро не осталось бы полицейских. Следователь не входит в совокупность инцидентов.

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

Это зависит от вашей проблемной области. Что делает ваша система? какова его область применения? какую проблему это решает?

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

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

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

Подумайте о жизненном цикле.

Answer 3

«Являются ли корни внутри корней хорошей идеей?»

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

public IEnumerable<Guid> InvestigatingOfficerIds 
{ 
    get { return _investigatingOfficerIds.AsReadOnly(); }
}

или

public IEnumerable<OfficerReference> InvestigatingOfficerIds 
{ 
    get { return _investigatingOfficerIds.AsReadOnly(); }
}

При этом OfficeReference - это класс, представляющий значение удостоверения офицера (под капотом, вероятно, будет Guid).

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