Это заняло некоторое время, но я чувствую, что начал формировать хорошее понимание агрегатов в DDD.Сохраняйте их маленькими (объект с объектами значений, когда это возможно) и, когда они содержат несколько объектов, убедитесь, что причина их существования заключается в применении некоторого (транзакционного) инварианта.
Когда я немного отменяю, это когда дело доходит доУдалить или удалить сторону вещей.Представьте себе:
Тема с сообщениями
В течение долгого времени я бы ошибочно принимал отношение "has-a" для агрегата, но ...
Требование, чтобыПост должен иметь поток, который может быть принудительно установлен с помощью фабричного метода в потоке, чтобы добавить сообщение.
Тогда вместо любых бизнес-правил, которые этого требуют, они могут быть отдельными агрегатами.Например, если вы загружали список тем, не имеет смысла загружать также все сообщения для каждой темы.
А как насчет удаления темы?Имеет смысл, что удаление темы означает, что сообщения для этой темы также должны идти.Но принудительное удаление сообщения при удалении его темы приводит к тому, что он становится единым агрегатом с потоком в качестве корневого агрегата.
Это просто типичный пример, но во многих случаях любой has-aОтношения часто подразумевают что-то подобное вышесказанному.то есть.ребенок больше не должен существовать, если родитель удален.
Итак, есть ли какой-либо совет относительно ситуации, когда единственной причиной, по-видимому, требующей совокупных отношений между двумя сущностями, является удаление / удаление?
Мое мышление на данный момент?
- Вы действительно не удалили тему.Вы делаете его неактивным.
- Когда тема становится неактивной, вы, очевидно, не можете добавлять новые сообщения (принудительно выполняется методом фабрики).Любые посты, которые принадлежат теперь неактивной ветке, также становятся неактивными из-за возможной последовательности?
Любые другие жемчужины мудрости, изученные, чтобы не смешивать отношения «есть» с совокупным корнем / потомкомсовокупность объектов?