在DDD / CQRS体系结构中处理伪聚合根

Question

I have the following classes:

class AggregateRoot
{
  // Defines common properties, Id, Version, etc.
}

class Container : AggregateRoot
{
  public IEnumerable<User> Users { get; }

  public void AddUser(User newUser)
  {
    // ...
  }

  // ...
}

class User
{
  public void AddNotification(Notification newNotification)
  {
    // ...
  }

  // ...
}

class Notification
{
  public string Message { get; set; }
}

As you can see I have a Container that contains one or more Users and each User can have zero or more notifications sent to them.

The most common operation in this scenario is adding new notifications, so I'll be retrieving a User quite often. Getting the User from the Container is possible, but then I need to retrieve the Container object and search in the Users collection. Which is fine if the Container is quite small and new. But as the Container gets older it gets more Users. So the Users collection can become quite big. My issue is that the User class is a pseudo aggregate root, lots of operations are done on the User, but a User can't exist outside of a Container. Solving the obvious performance problem with a new Repository storing Users presents another problem. How do I keep the User in the Users Repository in sync with the User in the Container?

I could store just the User Ids in the Container class, but that takes away the business logic in adding a new User to a Container because I can no longer do look up certain properties. So, how do I this?

I'm using MongoDb to store the events.

Answer 1

Solving the obvious performance problem with a new Repository storing Users presents another problem. How do I keep the User in the Users Repository in sync with the User in the Container?

You can implement the model in a slightly different fashion. If the only behavior on Container is the adding of User instances then you could make User an aggregate as well. To express the constraint that a user must be part of a container, a user could reference a container by ID.

class User
{
  public int ContainerId { get; private set; }
  public void AddNotification() //...
}

The Container class can still provide some of the behavior associated with adding a user. It could for instance provide a factory method for creating new users, which would be used by an application service which implements the use-case:

class Container
{
  public int Id { get; private set; }
  public User CreateUser(string userName)
  {
    return new User(this.Id, userName);
  }
}

class UserAppService
{
  public void AddUserToContainer(int containerId, string userName)
  {
    var container = this.containerRepository.Get(containerId);    
    var user = container.CreateUser(userName);    
    this.userRepository.Add(user);
  }
}

In this implementation, Container doesn't store a collection of users. This is so because as you point out, the collection can get very large and therefore unfeasible to manage in memory. In MongoDB, you'd have a container collection and a users collection.

Whenever you encounter this notion of a "pseudo-aggregate root" it is likely that you have two, possibly related aggregates. This is a common tactic for resolving these types of issues. For an in-depth treatment on the subject take a look at Effective Aggregate Design by Vaughn Vernon .