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?
"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.