Context mapping in Domain Driven Design
Context mapping is a tool that allows you to identify the relationship between bounded contexts and the relationship between the teams that are responsible for them.
Vaughn Vernon’s IDDD book describes several ways of how you can integrate between multiple bounded contexts:
- Partnership
- Shared kernel
- Customer supplier
- Conformist
- Anticorruption Layer
- Open Host Service
- Published Language
Each should be applied fluidly, depending on situations of the code, nature of the teams, the business itself, whether 3rd party software is involved etc. I will try to give an example of how these can be used.
Partnership
It describes more about the relationship between teams as oppose to actual code. This typically happens when 2 teams working on 2 bounded contexts have aligned and dependent set of goals. Each team should at least understand some of their partner’s Ubiquitous Language, namely the things that are interesting to their own context. This can work fairly well when both bounded contexts are at early stages of the project, where communication is quick and more efficient than implementing some of the other techniques. When both sides become more established, teams may incur too much commitment in understanding each other’s Ubiquitous Language. Of course, if a team was to work on both such bounded contexts, the ‘Partnership’ relationship would be much less costly.
Shared Kernel
2 or more bounded contexts can share a common model. In design terms, the Ubiquitous Language of this shared part is common both all relevent teams. In code terms, you may have a shared library, or a service. This is generally a small codebase but difficult to maintain as its related bounded contexts develop, as the teams will tend to go on separate ways as their own bounded contexts evolve.
Customer Supplier
This approach puts 2 bounded contexts into an upstream and downstream, where the upstream is the supplier, and has to try and meet the expectations of the customer (downstream). But the final decision of what the customer gets comes from the supplier. This typically works in an autonomous environment within the same organisation, or if the customer is the sole client of the supplier.
Conformist
This relationship describes the relationship of 2 bounded context, where the upstream has no interest in supporting the downstream for whatever reason. Instead, the downstream must conform to whatever the upstream provides. This can happen when integrating a new feature with a large, existing solution that is well established; or using a set of APIs, where the downstream is not the sole customer.
Anticorruption Layer (ACL)
This is another upstream/downstream relationship at a lower level, where the downstream bounded context implements a layer between itself and the upstream. This layer is responsible for translating the objects given by the upstream into its own models. This approach will guarantee the integrity of the downstream bounded context and keeps it completely ignorant of any foreign concepts. This approach is generally useful for integrating new features to some existing legacy software, where you can treat the existing legacy software as a black box bounded context and create an ACL for the new feature.
Open Host Service (OHS) / Published Language (PL)
I will talk about these two approaches together as they both define a relationship where the upstream provides a set of well documented or readily available information about the integration models. This is built on top of the Conformist approach from earlier, where the downstream is a lot more tolerable. The upstream will also need to provide version support. Typically the upstream bounded context will support multiple clients and have no interest in especially supporting particular one. For example, to conform to Amazon APIs, the downstream will have confidence in the integration by understanding the documentation Amazon provides.
In summary, understanding various context mapping techniques allows more effective integration between bounded contexts. It is also important to think about whether integration is necessary and brings benefits to the business in the first place. Using multiple approaches at the same time is also acceptable and sometimes preferred. For example, having a RESTful API naturally provides OHS, but at the same time, the downstream may also be encouraged to implement its own ACL, especially when the upstream service is by third party. Your team will be the best people to decide which approach(es) to use based on the current situation.
