How to determine when a root aggregate contains too many one-to-many relationships?

[c_sharp_dev1]

I am really struggling with the following scenario:

Let's say I have a user aggregate.  A user can create 1+ groups, messages, friends, photo galleries, etc.  Now it seems like groups, messages, friends, photo galleries should each be in their own aggregates groupings.  It seems illogical to create a user entity that contains an IList<> property for each one of these sections as opposed to just having a User property for groups, messages, friends, photo galleries, etc.  Which approach makes the most sense from a DDD perspective?  I am also thinking about entity hydration and it seems to make more sense to get groups, messages, etc. as needed instead of retrieving all from the user entity.  What is the recommended way to handling this scenario?

[c_sharp_dev1]

On Sunday, May 5, 2013 7:40:43 PM UTC-5, c_sharp_dev1 wrote:

I am really struggling with the following scenario:

Let's say I have a user aggregate.  A user can create 1+ groups, messages, friends, photo galleries, etc.  Now it seems like groups, messages, friends, photo galleries should each be in their own aggregates groupings.  It seems illogical to create a user entity that contains an IList<> property for each one of these sections as opposed to just having a User property for groups, messages, friends, photo galleries, etc.  Which approach makes the most sense from a DDD perspective?  I am also thinking about entity hydration and it seems to make more sense to get groups, messages, etc. as needed instead of retrieving all from the user entity.  What is the recommended way to handling this scenario?  Also, I am using dapper micro orm and EF 4.X POCO Entity Generator tool.

[Henrik Møller Rasmussen]

Hi

I would let the messages, photos etc. have a relation to the user, but not the other way around.

When you need to show photos for a user you can just query the photo repository for photos by user X.

If you put lists into the user model, then you would have to extend the user model every time you introduce new concepts in the future and the user model would grow very big. That is not wanted.

You can also look into bounded contexts and see if it makes sense for you to split the different model into different bounded contexts.

Best regards

Henrik

[Alexey Raga]

Does the User aggregate need to know about these links? Why? Which behavior/invariant includes this list? I doubt there is one.

Perhaps you would have it the other way around, say, a Group aggregate can have UserId in it, it may make sense.

[c_sharp_dev1]

Technically, these are items that a user would create but he is only aware of them when he is in that section.  The system should function just like a facebook-type scenario.  I am really trying to avoid a god aggregate situation.  It seems like my user entity should not have an IList for each of these other items(groups, messages, friends, etc.), while (groups, messages, friends, etc.) should each contain a reference to the user entity?  I am a newbie to DDD and this seems to be a point of confusion about how to properly structure this concept.

[Martin Jul]

Your intuition is right about avoiding the "god aggregate".

Like Henrik stated above, the relation should probably be the other way around e.g. from the Photo to the User who took the photo. 

I imagine your groups messages and user are Aggregate Roots. These refer each other symbolically (e.g. you hold an id, not the entity). This way you avoid loading your entire database when you load something that is connected to other objects (e.g. loading all the user's photos along with the user). 

References between Aggregate Roots would be via an ID or other key to use in a search on a repository.

You can design a repository to naviagate to the user from the photo like this, 

   userWhoPostedThePhoto = userRepository.GetById(photo.PostedByUserId)

Going the other way you would do do a query on the photo repository like this

 

   photosPostedByUser = photoRepository.FindPhotosPostedBy(user.Id)

Regards,

Martin