问题
I have the following DDD scenario, grouped into the following aggregates:
User,
Friends (User Associations),
File (for user uploading),
Galleries (grouping of files),
Messages (user communication),
Groups (users can create and other members can join),
GroupMessages (messages sent to all members of a group),
GroupForums (group members can discuss various topics)
This is where it gets confusing. A user is associated with everything down to GroupForums. It seems illogical to have to go through the User repository to access the other aggregates although, from a cascading standpoint, if I removed the user, technically, the records associated with the user should go away as well.
It seems as if I should not add all of the one-to-many associations that exist here to the user entity either, as hydrating from the database seems to be ridiculous, especially if I try pulling every record associated with the user. What is the recommended strategy for organizing your aggregates, and repositories as well as proper way of dealing with a lot of one-to-many relationships for a given entity?
回答1:
The fact that you used the word 'associated' in your sentence "A user is associated with everything..." is quite a clue. It is absolutely fine for aggregate roots to be associated or even for one to 'belong' to another. However, you need to look at whether an entity can exist without the AR. If it can it probably has its own life-cycle and should be an AR. If it can not it is part of the aggregate. This can be tricky to distill.
You need to have a very clear boundary around your ARs. For example, even though a Forum may require a User to create it this does not mean that the Forum needs to (or even can) be deleted when the user is deleted. So the User in the Forum may become, say, the ForumCreator (a value object) that contains the user name and id only. When the User is deleted then the forum can continue its existence.
In the Order/OrderLine/Product scenario it would not make much sense to delete all order lines that contain a specific product if you choose to delete it. I know that a product probably should never be deleted but we'll use it as an example. You would simply have the relevant product data 'denormalized' into the order line, e.g.: product id, product name. So even if the product name happens to change it does not mean that all order lines need updating, or even should be updated. In fact, the order line represents a point in time and the 'original' product name should be retained. The purchaser may have ordered 'Some lirril product' and then the name changed to 'Little product'. Not the same thing although it is the exact same product. The purchaser only remembers the original.
I hope that makes sense and helps in some way. You definitely need to find those hard edges to your object graph to get to the real aggregates.
来源：https://stackoverflow.com/questions/16378688/ddd-one-to-many-relationship-between-user-aggregate-root-and-almost-all-entitie