my questions is somewhat similiar to that by Sara Pellegrini but goes in a slightly different direction.
In general I try to understand the design principles of the CQRS ES application.
In doing so, my question is how to combine logic of Command Handlers and Event Listeners (and which are allowed and not allowed combinations):
If I got it right:
- Aggregate’s Comand Handler MAY emit Event but MUST NOT change the state (otherwise the state change can be restored for the aggregate based on stored event stream).
- Aggregate’s Event Sourcing Listener MAY change state, but MUST NOT emit events (otherwise, these events will be sasved in the event stream and will be duplicated on the aggregate re-creation)
- Aggregate’s Event Sourcing Listener and View’s Tracking Event Listeners MUST NOT not send Commands, because the replay will cause them to resend commands - except you construct the replay in a way Allard proposes in the post above.
- Saga’s Event Listeners MAY create new Commands. It is important that Saga association to some business entity detects/prevents duplication.
So thinking about interactions of several bounded contexts in more complex scenarios:
- Aggregate is the place to put connection from Commands to Events.
- Saga is the place to put the connection between Events to Commands.
Is that correct?
I can provide some examples for discussion if it is required,
but I think this is somehow fundamental and should not depend on examples.