CODEWITHSUNDEEP
domain-driven-designcqrs
Golo Roden
Golo Roden

Reputation: 150624

Should a single command address multiple aggregates?

In CQRS and DDD, an aggregate is a transactional boundary. Hence I have been modeling commands always in such a way that each command always only ever addresses a single aggregate. Of course, technically, it would be possible to write a command handler that addresses multiple aggregates, but that would not be within a single transaction and hence would not be consistent.

If you actually have to address multiple aggregates, I usually go with a process manager, but this sometimes feels like pretty much overhead. In addition, from my understanding a process manager always only reacts to domain events, it is not directly addressed by commands. So you need to decide which aggregate to put the starting point to.

I have seen that some people solve this using so-called domain or application services, which can receive commands as well, and then work on multiple aggregates – but in this case the transactional nature of the process gets lost.

To give a simple example, to better illustrate the scenario:

Where to put the command that triggers the initial joining process, and what to call it? user.join(group) feels as right or wrong as group.welcome(user). I'd probably go for the first one, because this is closer to the ubiquitous language, but anyway…

If I had something above the aggregates, like the aforementioned services, then I could run something such as:

userManagement.addUserToGroup(user, group);

However, this addUserToGroup function would then need to call both commands, which in turn means it has to take care of both commands being processed – which is somewhat counterintuitive to having separate aggregates at all, and having aggregates as transactional boundaries.

What would be the correct way to model this?

Upvotes: 3

Views: 1490

Answers (2)

expandable
expandable

Reputation: 2290

Essentially what you have is many to many relationships between users and groups with restrictions on both sides:

  • Restriction on the number of groups a user can join
  • Restriction on the number of users a group can have

VoiceOfUnreason already gave a great answer, so I'll share one way I've solved similar problems and go straight to the model and implementation in case you have to ensure that these constraints are enforced at all costs. If you don't have to, do not make the model and implementation that complex.

Ensuring consistency with such constraints on both Group and User entities will be difficult in a single operation because of the concurrency of the operations.

You can model this by adding a collection of RegisteredUsers to a Group or vice versa, adding a collection of JoinedGroups to a User, and enforce the constraint on one side, but enforcing it on the other side is still an issue.

What you can do is introduce another concept in your domain. The concept of a "Slot" in a Group. "Slots" are limited by the max number of Slots for a Group.

Then a User will issue a JoinGroupRequest that can be Accepted or Rejected.

A Slot can be either Taken or Reserved. Then you can introduce the concept of SlotReservation. The process of joining a User to a Group will be:

  • Issue a JoinGroupRequest from a User
  • Try to Reserve a Slot enforcing the MaxUsersPerGroup constraint.
  • Acquire a Slot or Reject the SlotReservation of a User enforcing the MaxGroupsPerUser constraint.
  • Accept or Reject the JoinGroupRequest depending on the outcome of the SlotReservation

If the SlotReservation is Rejected, another User will be able to use this Slot later.

For the implementation, you can add SlotReservation Queue Per Group to ensure that once a Slot is free after a Rejected SlotReservation, the next User that wants to join the Group will be able to.

For the implementation, you can add a collection of Slots to a Group, or you can make Slot an aggregate in its own right.

You can use a Saga for this process. The Saga will be triggered when a JoinGroupRequest is made by a User.

Essentially, this operation becomes a Tentative Operation.

For more details take a look and the Accountability Pattern and Life beyond distributed transactions an apostate's opinion and Life beyond distributed transactions an apostate's implementation.

Upvotes: 3

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57249

It may be worth reviewing Greg Young on Eventual Consistency and Set Validation.

What is the business impact of having a failure

This is the key question we need to ask and it will drive our solution in how to handle this issue as we have many choices of varying degrees of difficulty.

And certainly Pat Helland on Memories, Guesses, and Apologies.

Short version: the two generals tell us that, if two pieces of information must be consistent, then we need to write both pieces of information in the same place. The "invariant" constrains our data model.

The invariant you describe is effectively a couple of set validation problems: the "membership" collection allows only so many members with user A, and only so many members with group B. And if you really are in a "we go out of business if those rules are violated" situation, then you cannot distribute the members of that set -- you have to lock the entire set when you modify it to ensure that the rule is not broken and that first writer wins.

An element that requires some care in your modeling: is the domain model the authority for membership? or is the "real world" responsible for membership and the domain model is just caching that information for later use? You want to be very careful about trying to enforce an invariant on the real world.

There's a risk that you end up over constraining the order in which information is accepted by the model.

Upvotes: 3

Related Questions