Saga's and Query model transaction ordering

Question

I have the following Ubiquitous language defined by our domain expert: A User can find UserGroups and add himself to it. A user can query a list of UserGroups where he is member of and remove himself from it. UserGroups are created by Users, where the creator is the first member. When there is no more User in the UserGroup, the UserGroup should be deleted from the views.

As UserGroups can become pretty big, by following "Effective Aggregate Design", I came to the following {AR}'s:

{User}<--(UserId)--{UserGroupMember}--(UserGroupId)-->{UserGroup}

All fine, except how to make the last rule (When there is no more User in the UserGroup, the UserGroup should be deleted from the views.) work with this model?

I've considered a saga that listens to UserGroupMemberLeft event, queuing the nr of members and if 0 delete the group. But as it queries the read-model, I have an ordering problem as the read-model is eventually updated as well. How to solve this? Should I consider a ReadModelUpdated event as well?

Answer 1

All fine, except how to make the last rule (When there is no more User in the UserGroup, the UserGroup should be deleted from the views.) work with this model?

It's a constraint on the query executed by the read model to create the view.

This may mean that you need to update the read model to support the constraint. For instance, in your original implementation, you might have have supported the view of user groups with a Set, where each group would be inserted into the set when it was created.

With the new requirement, the read model now needs to track total membership. So you replace the Set with a Map, with you used to track the count of users added and removed from the group. When you need a view of groups, you enumerate the entries in the hash to find the groups that satisfy the constraint (subscribedMembers > unsubscribedMembers).

Note that these details live purely in the read model -- the requirement as described didn't impose any restrictions on the write model. Based on your comment about UserGroupMemberLeft, it looks like you are trying to introduce end of life to the model.

As pointed out by @JDT, some aggregate needs to be responsible for the end of life. What state determines if the delete of a group is allowed? The aggregate that controls that state is the one that should be responsible for the end of life operation, since it's the only one that knows if the retirement of the group is allowed.

I don't know your domain, but I'd guess that the group itself contains the required state. For instance, if you aren't allowed to retire a group more than once, then it's probably the group that is tracking that. Similarly, if you are only allowed to retire empty groups, its probably the state of the group that is tracking that.

So I assume the group is responsible for its own retirement. At this point, you have two options available to you. One is a process manager, which observes the membership counts and sends a command to retire the group when it observes that there are no members. Because of eventual consistency, this command might be rejected -- for instance, if a new member joins the group after the last one has left.

If you need to retire the group in a transactionally consistent way, then the group locks itself against further enrollment as part of the transaction when the last member leaves. For example, if the write model is broadcasting events to the read model, then the departure of the last user would generate two events, one describing the user leaving, and a second describing the retirement of the group.

Since the group locks itself when the last member leaves, you don't need to worry about the race condition.

Done this way around, your read model can use the Set implementation from earlier, adding groups to the set when they are first created, and removing them when the group is retired.

Answer 2

The thing lacking in your domain language is the concept of WHO should delete the group. Users can create groups and add themselves to it, which puts the responsibility for those actions clearly on the users. But you go on to say that 'groups should be deleted'. From a business perspective, this makes no sense.

If your requirement is rephrased to "When there is no more User in the UserGroup, the User should delete the group " it becomes obvious who's responsibility it is to remove the group.