Monolithi c агрегатные корни

Question

Как мы имеем дело с агрегатными корнями, которые имеют огромное количество агрегатов под ним?

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

Если Person Является ли совокупность root всех этих объектов, как мне избежать наличия огромного хранилища, которое пытается охватить все это?

Хорошо, если каждая из этих вещей является их собственной совокупностью root, что может иметь свои собственные репозитории, и я занимаюсь всей проблемой обеспечения каскадного удаления при удалении Person?

Answer 1

Aggregate Root предоставляет способ управления доступом к вашим объектам в пределах Domain. Это не обязательно означает, что у вас всегда должен быть один Агрегат Root. Совокупность Root должна определяться исходя из ваших бизнес-требований и не обязательно того, как они хранятся в базе данных.

Если обновление одной части вашего домена влияет на другую часть домена. Тогда Domain Events может помочь.

От Событие домена Microsoft Docs определяется следующим образом:

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

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

Тем не менее, вы не должны создавать дополнительные Агрегированные Корни, если они не соответствуют вашему варианту использования только потому, что они громоздки. Если совокупность Root огромна по всем правильным причинам, вы можете использовать языковые функции c, чтобы разделить совокупность Root. Например, в C# у нас есть понятие partial class. Вы можете потенциально создать несколько partial Person классов и разделить операции на разные файлы (если используете C#).

Answer 2

«Владение» не обязательно подразумевает агрегирование.

Например, Customer «владеет» одним или несколькими экземплярами Order, но они не являются частью совокупности Customer, так как они имеют свои собственный жизненный цикл.

Каскадное удаление может быть применено вашей технологией баз данных, хотя это еще одно обсуждение. Вероятно, редко нужно или нужно удалять экземпляры из базы данных. Деактивация Customer может быть более осуществимым подходом. Это является еще большей проблемой, когда речь идет об аудите и / или законодательстве и т. П., Где необходимо хранить данные в течение минимального периода времени. Архивирование является еще одним вариантом.