Monolithic aggregate roots

1
votes

How do we deal with aggregate roots that have an enormous amount of aggregates beneath it?

Say I have a Person as my aggregate root, and there are a large number of entities that represent all the various activities and things that a person can do. Each of these are distinctly separate from each other and have their own life-cycle and may be stored in different databases. They are all dependent on the life-cycle of the Person however, if the Person is ever removed they all need to be deleted as well because they are no longer relevant.

If the Person is the aggregate root of all of these objects, how do I avoid having an enormous repository that tries to cover all of these?

Is it okay if each of these things are their own aggregate root that can have their own repositories, and I deal with the whole issue of ensuring the cascading deletes if a Person is ever removed?

2
domain-driven-designaggregateroot
Can you please provide a concrete example of such a huge aggregate and invariants which must be protected? - DmitriBodiu
I don't have a fleshed out example right now, starting to define the domain I'm working on.I think the the answers provided by Eben Roux and Ankit Vijay are pointing me in the right direction on what I need to do. - Cowman
I would suggest to provide a prototype of your domain model, at least how you see it even if its wrong. Then I can help you to identity the boundaries. ;) - DmitriBodiu

2 Answers

1
votes

"Ownership" does not necessarily imply aggregation.

For instance, a Customer "owns" one or more Order instances but those are not part of the Customer aggregate since they have their own life-cycle.

Cascading deletes can be enforced by your database technology although that is another discussion. One probably would rarely need to, or want to, delete instances from a database. Deactivating a Customer may be a more feasible approach. This is even more of an issue when dealing with auditing and/or legislation and the like where one would need to store data for a minimum period of time. Archiving is another option.

1
votes

AnAggregate Root provides a way to control the access to your entities within the Domain. It does not necessarily mean that you should always have one Aggregate Root. What should be an Aggregate Root should come from what your business requirements are and not necessarily how they are stored in the Database.

If updating one part of your Domain has an impact on another part of the Domain. Then, Domain Events can help.

From Microsoft Docs domain event is defined as follows:

A domain event is something that happened in the domain that you want other parts of the same domain (in-process) to be aware of. The notified parts usually react somehow to the events.

Since the Domain Events are in-memory you can do a commit or rollback of "the entire transaction" at the end of the lifecycle.

That said, you should not create additional Aggregate Roots if it does not fit your use case just because it is bulky. If the Aggregate Root is huge for all the right reasons, you could use Language-specific features to divide your Aggregate Root. For example, in C# we have the concept of partial class. You could potentially create a multiple partial Person classes and divide the operations into different files (if using C#).