title: When do domain event handlers come into play?
body: <p>I have a simple examle domain of two aggregate roots and one regular entity.
  <code>Tenant</code>, <code>UserGroup</code> and <code>User</code> where in this particular sample the <code>Tenant</code> and <code>User</code> make up for the two <strong>AggregateRoots</strong>.</p>
  
  <p>When a command is received from the UI/Service layer it reaches the command handler which manipulates the write only domain.</p>
  
  <p>You could say that <code>User</code> isn't supposed to be an <strong>AggregateRoot</strong> at all but since it will be referenced by others, it cannot be a regular entity. (yes?)</p>
  
  <p>These two AggregateRoots need to communicate. A <code>User</code> cannot be created without belonging to a <code>UserGroup</code>, which is an entity in the bounded context of <code>Tenant</code>. Presumably, we can create, since it is a simple constraint, a User through the constructor. <code>User.Create(TenantId, UserGroupId)</code> </p>
  
  <p>It generates a <code>DomainEvent</code> with Date, AggregateVersion and AggregateId (of the user). Now we get to the blurry parts.</p>
  
  <p>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 <code>Tenant</code>'s <code>UserGroup</code> to add the <code>UserId</code>? </p>
  
  <p>Are my thoughts about solving this going into the entirely wrong direction?</p>