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?
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With