Question

This is a question on domain model design.

Let’s say for a domain design involving users and groups, we have the following interfaces to implement:

interface IUser
{
    string Name{get;}
    DateTime DOB {get;}
}

interface IGroup
{
    string Name {get;}
    bool IsUserInGroup(IUser user); // #1
    void IncludeUser(IUser user);   // #2
    void ExcludeUser(IUser user);   // #3
}

interface IUserRepository
{
    IUser Create(string name);
    IUser GetByName(string name);
    void Remove(IUser user);
    void Save(IUser user);
}

interface IGroupRepository
{
    IGroup Create(string name);
    IGroup GetByName(string name);
    void Remove(IGroup group);
    void Save(IGroup group);
}

The tricky bit is to implement #1 #2 and #3 while keeping the entity classes (User, Group) decoupled from the repository classes (UserRepository, GroupRepository.)

Another technicality to consider is that most RMDB systems do not implement many-to-many relationships, and in practice there is always a separate table (say, UserGroupAssociation) to have records each associates a user and a group via foreign keys. I would like to hide this implementation detail from the domain interfaces and expose the equivalent logic through members #1 #2 and #3.

The effect of calling #2 and #3 should not persist until the group object in question has been saved (i.e. passed to the Save() method of the repository object)

How do you usually do it?

Answer 1

I don’t do it. My Repository objects are tightly coupled to the root of the aggregate to which they relate, and (as kind of an aside) I don’t bother making interfaces for my domain model objects unless I find I have a good reason to do so – do you have a particular reason to do this?

I’ve not come across any Repository examples which don’t use the entity implementation type in the repository class (this one, for instance) and can’t think of any real advantage of using an interface instead. Interfaces earn their keep for infrastructure components (like a Repository) by making it easier to mock out entire layers of the system when testing, you don’t get the same type of advantage using interfaces for domain objects.

And to perhaps actually answer the question…

I never have a domain object access a Repository – the domain object after all is supposed to represent something in the domain in real life, and Repositories are infrastructure components that don’t exist in real life, so why would a domain object know about one?

For the specific example of adding a User to a Group, I’d use a Service Layer class, and do this:

public class UserService
{
    private readonly IGroupRepository _groupRepository;
    private readonly IUserRepository _userRepository;

    public UserService(
        IGroupRepository groupRepository,
        IUserRepository userRepository)
    {
        this._groupRepository = groupRepository;
        this._userRepository = userRepository;
    }

    public void IncludeUserInGroup(string groupName, string userName)
    {
        var group = this._groupRepository.FindByName(groupName);
        var user = this._userRepository.FindByName(userName);

        group.IncludeUser(user);

        this._userRepository.SaveChanges();
    }
}

public class User
{
    public void AddToGroup(Group group)
    {
        this.Groups.Add(group);
    }

    public void RemoveFromGroup(Group group)
    {
        this.Groups.Remove(group);
    }
}

Some points to note:

1. To avoid lazy-loading large numbers of Users when adding a User to a Group I’ve moved the Group administration methods onto User – depending on how much behaviour you actually have for Group, you might even consider turning it into an enumeration rather than a class. Be aware that if you’re using the Entity Framework POCO T4 Templates with FixupCollections, this will still lazy-load all the Users in a Group, but you can get around that in one way or another 🙂

2. The Service Layer class would implement a Create() method, the like of which you have on your Repositories. The Repositories would have an Add method, Find methods and a SaveChanges() method. Add would add an object created by the Service Layer to the object context.

3. All Repository classes would be set up to use the same underlying, request-scoped object context, so it wouldn’t matter which one you call SaveChanges() on.

4. SaveChanges() would cause all changes which had happened to objects during that request to be saved, such as a User having a new Group‘s added to their Groups collection.

Finally, another good technique for decoupling entities from Repositories and other infrastructure components is Domain Events.