Communication between contexts in a domain-driven project
At my company we are currently working with DDD architecture combined with event source and CQRS. In the original version, we allowed each context to receive events from any other context. This, however, quickly became a mess because it became very difficult to keep track of what events were being processed there.
Our current approach is to only send commands to other contexts. This works better, but seems to generate a lot of code overhead. For example:
context A sends a command to context B,
which changes the state of a domain model,
which publishes an event,
which gets handled by an event handler,
which sends a command back to context A,
which changes the state of a domain model,
which publishes an event,
which gets handled by an event handler,
which sends a command to context C,
etcetera.
Many domain models in different contexts and many events that trigger a command sent to a different context contain a lot of similar data. Especially in the context of our client site, models contain almost no logic or state and are simply used to generate events that can be denormalized to the website's database. It works, but still it doesn't seem like it should go as event publishing shouldn't be the sole purpose of any domain model.
One of our ideas was to make our CMS act like a domain model and handle commands directly, rather than send them through the model and handle the resulting events. Is this the correct way to handle such cases? And are there other, more effective ways to communicate between contexts?
source to share
In the original version, we allowed each context to receive events from any other context. This, however, quickly became a mess because it became very difficult to keep track of what events were being processed there.
I don't see a problem with this alone. Communication between BCs via events is a typical event-driven architecture. Tracking events can be done using a context map.
It seems, however, that in your case, the BC interactions have become overly chatty. This could be a sign of suboptimal boundaries. Are the borders too grainy? Considering that several domain models contain a lot of similar data, it can be indicated that these domains should be merged. The underlying BC principle is functional and linguistic cohesion - things that are closely related to each other.
The domain model change state in response to a command followed by an event publication is a fully valid workflow.
Especially in the context of our client site, models contain almost no logic or state and are simply used to generate events that can be denormalized to the website's database.
This is similar to a presentation / forecast in terms of CQRS. Again, there is nothing wrong with this.
One of our ideas now was to make our CMS act like a domain model and handle commands directly, rather than dispatching them through the model and handling the resulting events.
This can be an important observation. A complete domain model makes sense when the business logic is complex. However, if the domain is a CMS or CRUD domain , then there is no need for a domain model. However, you can still keep the rest of the event driven architecture.
source to share