Question

I have a simple examle domain of two aggregate roots and one regular entity.
Tenant, UserGroup and User where in this particular sample the Tenant and User make up for the two AggregateRoots.

When a command is received from the UI/Service layer it reaches the command handler which manipulates the write only domain.

You could say that User isn’t supposed to be an AggregateRoot at all but since it will be referenced by others, it cannot be a regular entity. (yes?)

These two AggregateRoots need to communicate. A User cannot be created without belonging to a UserGroup, which is an entity in the bounded context of Tenant. Presumably, we can create, since it is a simple constraint, a User through the constructor. User.Create(TenantId, UserGroupId)

It generates a DomainEvent with Date, AggregateVersion and AggregateId (of the user). Now we get to the blurry parts.

Open committing this event into the store, this event is broadcasted onto the bus (memory, whatever). It this the point where domain’s event handlers, similar to command handlers, catch the user created and notify/manipulate the Tenant‘s UserGroup to add the UserId?

Are my thoughts about solving this going into the entirely wrong direction?

Answer 1

A Saga might be what you are looking for.

Simply put: A saga can be implemented as an event handler that listens for specific events and issues commands to different aggregate roots, or even across context boundaries.

In your case it might look like this:

public class RegisterUserSaga : Handles<UserCreated>
{
    public void Handle<UserCreated>(UserCreated evnt) {
        var tenantId = // you probably know how to find this
        var groupId =  // same here
        var command = new RegisterUserForTenant(evnt.UserId, tenantId, groupId);
        Bus.Send(command);
    }
}

Read more about sagas in this article by Rinat Abdullin or watch “CQRS, race conditions, and sagas – oh my!” by Udi Dahan

Update:

After our extended discussion in the comments I’ll try to show how this could work from a different angle (pseudo code ahead). This hopefully sheds some more light on a possible solution:

// Aggregates:

Tenant
    Guid TenantId
    List<Guid> UserGroups

UserGroup
    Guid UserGroupId
    List<Guid> Users

User
    Guid UserId
    Some more details

// Commands:

RequestRegistration(userId, userGroupId, user details)
CreateUser(userId, user details)
AddUserToGroup(userId, userGroupId)

// The initial command would be:

RequestRegistration (leading to a RegistrationRequested event)

// The Saga handles the RegistrationRequested and all subsequent events

UserRegistrationSaga 
    Handle(RegistrationRequested)
    -> send CreateUser command (which eventually leads to a UserCreated event)
    Handle(UserCreated)
    -> send AddUserToGroup command (-> UserAddedToGroup event)
    Handle(UserAddedToGroup)
    -> Done