What Is Domain-Driven Design?

Chapter 4. Context Mapping

Not only does the bounded context pattern protect the consistency of a ubiquitous language, but it also enables modeling. You cannot build a model without specifying its purpose—its boundary. The boundary divides the responsibility of languages. A language in one bounded context can model the business domain for the solving of a particular problem. Another bounded context can represent the same business entities, but model them for solving a different problem.

Moreover, models in different bounded contexts can be evolved and implemented independently. That said, bounded contexts are not independent. A system cannot be built out of independent components; the components have to interact with one another to achieve the overarching system goals. The same goes for bounded contexts. Although their implementations can evolve independently, they have to integrate with each other. As a result, there will always be touchpoints between bounded contexts. These are called contracts.

The need for contracts results from differences in bounded contexts’ models and languages. Since each contract affects more than one party, they need to be defined and coordinated. Also, by definition, two bounded contexts are using different ubiquitous languages. Which language will be used for integration purposes? These integration concerns should be addressed by the solution’s design.

In this chapter, you will learn about domain-driven design’s patterns for defining relationships ...