That’s the reason why the use of a shared kernel has to be justified. The overlapping model-the shared kernel-is, in effect, being developed by multiple teams. If the participating bounded contexts are not implemented by the same team, introducing a shared kernel contradicts the principle that a single team should own a bounded context. In a sense, the shared kernel pattern contradicts the principles of bounded contexts introduced in the previous chapter. Therefore, the shared kernel will naturally be applied for the subdomains that change the most: the core subdomains.

The more frequently it changes, the higher the integration costs will be. The difference between the integration and duplication costs depends on the volatility of the model. Since the pattern introduces a strong dependency between the participating bounded contexts, it should be applied only when the cost of duplication is higher than the cost of coordination-in other words, only when integrating changes applied to the shared model by both bounded contexts will require more effort than coordinating the changes in the shared codebase. The overarching applicability criterion for the shared kernel pattern is the cost of duplication versus the cost of coordination. We will divide the patterns into three groups, each representing a type of team collaboration: cooperation, customer–supplier, and separate ways. These patterns are driven by the nature of collaboration between teams working on bounded contexts. In this chapter, you will learn about domain-driven design patterns for defining relationships and integrations between bounded contexts. Which language will be used for integration purposes? These integration concerns should be evaluated and addressed by the solution’s design. Also, by definition, two bounded contexts are using different ubiquitous languages. Since each contract affects more than one party, they need to be defined and coordinated. The need for contracts results from differences in bounded contexts’ models and languages. As a result, there will always be touchpoints between bounded contexts. Although they can evolve independently, they have to integrate with one another. Just as a system cannot be built out of independent components-the components have to interact with one another to achieve the system’s overarching goals-so, too, do the implementations in bounded contexts. That said, bounded contexts themselves are not independent. Moreover, models in different bounded contexts can be evolved and implemented independently. Another bounded context can represent the same business entities but model them to solve a different problem. A language in one bounded context can model the business domain to solve a particular problem. The boundary divides the responsibility of languages.

You cannot build a model without specifying its purpose-its boundary. Not only does the bounded context pattern protect the consistency of a ubiquitous language, it also enables modeling.

Ddd bounded context