In domain driven design based on domain events, I have the impression that several sources pronounce the rule that
- aggregates consume commands and produce events
- process managers consume events and produce commands
I am aware that in event sourcing, the aggregate must consume events as well, but then they are usually the events produced by the aggregate itself. So I don't see this as a contradiction.
My question would be: What is the foundation for this rule?
For example: Which negative consequences would an aggregate have, that directly consumes events produced by another aggregate? Is it the same if the aggregates are located in different bounded contexts and therefore have separate languages?
Best Answer
In DDD, the Aggregates are the only one that are allowed to mutate the system state, so they are the only one that receive and execute commands and produce the state mutations. This is because they need to enforce the business rules.
The state mutations are then returned to the caller, most probable an Application service that persist them in a database.
In Event sourcing, the state mutations are the domain events.
The Process managers/Sagas use the state to decide what is the next course of actions for the business processes that they manage.
In Event sourcing, the state is built from the events, that's why they consume events -> to build their needed state.
It is like the two aggregates would share the same table, or parts of it, in a non-event-sourced architectural style, which is very bad. The Aggregate must own its state and it must be independent of external state or services.
Yes, but I wouldn't say a different bounded context but a different context. An Aggregate could receive data that is owned by a different Aggregate, but only after it is translated to its language (its command) by the caller, that could be an Application service, a Process manager/saga etc.