DDD: How should adding and removing related entities be modelled?

Question

Say we have two aggregate roots in a domain model: Group and User.

Now, Users can be added to or removed from groups. Using the repository pattern, I only modelled the following two interfaces so far:

interface IGroupRepository
{
    Group FindById(int groupId);
}
interface IUserRepository
{
    User FindById(int userId);
    IQueryable<User> GetGroupMembers(int groupId);
    void AddUserToGroup(User user, Group group);
    void RemoveUserFromGroup(User user, Group group);
}

Somehow, the doesn't feel right. I want to achieve a clean domain model and not end up with a mere data-access layer. What would be a better way to model the above?

EDIT: The root question here seems to be, is it OK with DDD's guidelines to treat User as a 'sub-object' while it at the same time is an aggregate root as well? As I understood DDD, it states that aggregate roots must only be retrieved and stored from one place (the repository) so that's why I get a bit confused.

Answer 1

If you use a ORM such as NHibernate to it's full potential you can have methods like this:

class Group
{
    List<User> members;

    void Join(User user)
    {
        members.Add(user);
    }

    void Leave(User user)
    {
        members.Remove(user);
    }
}

A decent ORM will track the changes to the members list and persist those to the database.

This would enable your interfaces to be simplified to:

interface IGroupRepository
{
    Group FindById(int groupId);
}

interface IUserRepository
{
    User FindById(int userId);
}

This should give you some guidance on doing this with NHibernate.

Answer 2

It is ok for the domain model to be close to the data-access layer. If it wasn't than you probably have a problem (with the database design). The idea of separating the domain model is to have good separation which in turn will give you more freedom. It is and not just to be different...

You will still have your data-access layer, but the domain model will be very simple (just propagating calls).

Answer 3

In this case I would consider creating a collection of Groups on the User or vice versa. That way you do not need a specialized method on the repository. Most ORM frameworks support this kind of mapping

public class User
{
    public virtual ICollection<Group> Groups {get;set;}
}