Managing Complexity in Communications between Multiple Bounded Contexts in DDD

Question

I am starting to work on a system based on Domain-Driven Design (DDD), and I have divided my application into multiple bounded contexts to reflect different business areas. However, I have noticed that these bounded contexts need to communicate with each other to maintain the system's coherence and consistency.

Initially, I plan to use a message queue to facilitate communication through events between the bounded contexts. However, I still have concerns about the complexity that may arise due to the large number of interactions between them.

For example, the "Price Catalog" context needs to communicate with the "Article Catalog" context, which, in turn, needs to interact with the "Billing" context. These relationships seem to form a web of communications that could make the system challenging to handle and maintain.

I wonder if there are any strategies or best practices to simplify managing communication between many bounded contexts. What additional approaches can I consider to reduce the complexity of interactions between these contexts and avoid potential inconsistencies? Are there any design patterns or techniques that can help handle this situation more efficiently and effectively?

I appreciate any advice or experience you can share to address this concern and maintain a coherent and manageable DDD system.

Answer 1

Strategic view: Splitting the domain

When creating a domain model, we often split it in many bounded contexts as a design choice, but this makes it hard to maintain for the reasons you mention (that is, the necessity of maintaining a web of communications between the multiple bounded contexts).

One consideration you could do is to verify that your domain needs actually to be divided in so many bounded contexts or not.

Start from the conception of your whole domain and try to identify subdomains (that are, parts of the domain that are described by similar use cases, use cases that share one trait or theme or topic). A subdomain is not something that depends on design decisions, it is something that is already there, that divides naturally your domain, and that you only need to discover. List your whole set of use cases and group them by similarities: the groupings are your subdomains.

Then, do some design considerations over subdomains, to create bounded contexts. Remember, indeed, that a while subdomains are something to be discovered, the creation of bounded contexts is a design choice. The easy-to-go approach is to create a bounded context for each subdomain. If you think that for design purposes it is better to further split a subdomain in multiple bounded contexts, then go for it.

In your specific case, consider whether you want to broaden the scope of the bounded contexts you have already created, and that maybe such a context contains multiple aggregates.

Tactical view: Communication between contexts

Integrating bounded contexts should not consider the case in which the first bounded context calls out directly for the second bounded context, because in this way you would require both the bounded contexts to be alive and responsive at the same time.

A possible approach for integrating the bounded contexts is via domain events, which are:

• generated by the first bounded context as a byproduct of some action (e.g., an entity is created, a status of an aggregate is changed)
• captured by the second bounded context, that reacts to them accordingly

One of the perks and challenges of this approach is that the system as a whole now answers to eventual consistency (here for reference), meaning that the first bounded context fires the event and forgets about it, the second bounded context at a certain point in time will capture the event and react, but you admit that for a certain period of time there could be misalignment (or inconsistency) between the two contexts. You then accept that the two contexts will become consistent eventually.

(Another approach would be also to make the mechanism synchronous, but this comes with its own complications)

For reference you could look at the CQRS architecture (here for reference). It does not cover exactly your scenario, as it is more about having a write model and multiple read models and the need of maintaining those models aligned in time (usually via the usage of domain events). However, the way the multiple models are maintained aligned could be of inspiration for your case.