Domain event publisher inside DomainEventsDispatcher

[lukaszdobrzynski]

Hello @kgrzybek

First of all, thank you for letting the community learn from this repository.

I have a question about the DomainEventsDispatcher class. One of the things it does is read domain events published by an aggregate to be further processed as part of the very same transaction if need arises. For example, UserRegistrationConfirmedDomainEvent is published by UserRegistration aggregate, which in turn is handled by UserRegistrationConfirmedHandler as a subscriber. All this happens in the piece of code shown below:

_domainEventsProvider.ClearAllDomainEvents();
foreach (var domainEvent in domainEvents)
{
    await _mediator.Publish(domainEvent);
}

Why would the class want to expose such an option?

If I understand the structure of the flow correctly, the approach allows changing the state of two or even more aggregates within the same transaction boundary, depending on the number of subscribers to the original event. In other words, there is nothing to stop us from modifying the state of not just one but many aggregates at the same time. Is that acceptable? What would the best practice be here?

[bojanz27]

This architecture (as any other) is opinionated on the topic of DomainEvent.

In general you have two takes:
(A) domain event handlers run in the same transaction as the original operation that raised the event.
(B) domain event handlers run after the original transaction has been committed

The architecture of this repo obviously goes with the (A).

IMO This gives an elegant way to implement "transactional workflows" - when you need to actually affect multiple aggregates inside the same transaction - instead of having procedural code (in your command handler for example) making calls on one aggregate after another, you instead react to a DomainEvents.

I don't think there's any rule or best practice that this approach breaks. It's just a take that may or may not be suitable for your use case.

This repo also gives you "out of transaction" handlers via IDomainEventNotifications.

[lukaszdobrzynski]

@bojanz27

As every architectural decision this one also has a trade-off.

With the reactive approach and multiple aggregates publishing their events in a single transaction the code needs to be able to track the entire chain. If an aggregate A publishes an event and that event is handled by invoking a behavior on aggregate B in the same transaction, it becomes relevant that the transaction scope does not lose the events published by aggregate B as well. Moreover, the events published by aggregate B may also be handled in a similar fashion. This may obviously lead to the events getting out of control and the flow turning into the event hell.

When exploring the project I did not discover a piece of code that would allow tracking the entire "in transaction" event chain. It appears that only events published by aggregate A can be handled "in transaction" and later turned into domain notifications. Events published by aggregate B as the next possible chain link are omitted and not taken into account. I'd be curious to know if that is intended. Is it the way to prevent the event hell from happening? Is there any other motivation behind such decisions?

Obviously, I may have missed something since the code base seems to be complex. Nevertheless, I've learnt a lot from this project and I find it a valuable educational resource.

[i-vukman]

@lukaszdobrzynski There is a IDomainEventsDispatcher that dispatches events and saves outbox message if there are any notification handlers registered for events being dispatched.

This is being executed in 2 places:

1. In UnitOfWork - just before the changes being saved to the DB.
2. In DomainEventsDispatcherNotificationHandlerDecorator - if any additional aggregate gets updated and publishes any new domain events, it will be handled by this decorator.

With these two in place, "in transaction" event chain is being handled.