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?
Even without knowing much about your particular business domain, it does sound very wrong to have the User class as a sort of God aggregate with everything else underneath it.
Grouping your entities into larger ones with an aggregate root is completely up to how your business works. For instance, PhotoGallery could be an aggregate root with many Photo objects underneath it, or both PhotoGallery and Photo could both be separate aggregate roots.
For example you might run a photo development company, where photos are always collected, handled and processed as a complete PhotoGallery (1 aggregate root).
Or you might run a social networking site, where a Photo can be shared and used commonly without needing to load the whole gallery (2 aggregate roots).
So it's really up to you and what your business domain dictates. You can always suck-it-and-see, try things one way and see how it goes, then refactor later.