Bounded context

One fallacy of monolithic thinking is the master data model (MDM). Virtually every decent-sized enterprise has made an attempt at crafting a master data model that describes all the data entities used by the enterprise and the relationships between those entities. It's a noble goal to create a shared definition of all the data within a company and across all its systems and processes. Yet these projects drag on and on, filled with meetings full of more people then can be fed with two pizzas. There is endless debate about the details of the model and ultimately any model that is created is utterly bloated with details that are irrelevant for most systems and scenarios. In the end, these models actually impede progress, because they lend themselves to the creation of monolithic systems that are neither bounded nor isolated. I was recently involved in a cloud migration project for a legacy system that was plagued by an unbounded data model. Several separate but somewhat related concepts were intertwined in the same relational data model. These concepts shared the same terms, but they had different meanings for different teams. Design discussions frequently went off track when the terms and meanings were mixed up. Ultimately, innovation in the legacy system came to a standstill, because no one was confident that they could make enhancements to the broken model. The model needed to be revamped into several bounded contexts.

No book on cloud-native would be complete without covering the concept of bounded contexts. Bounded contexts are a core concept in Domain Driven Design (DDD). Domain Driven Design embraces the fact that there is no single unified model. Large models are decomposed into multiple bounded contexts with well-defined interrelationships. Each bounded context is internally consistent, such that no terms have multiple meanings. When concepts do overlap between bounded contexts, these relationships can be depicted with a context map. Domain events are used to communicate between the different contexts. What emerges is a ubiquitous language that facilitates communication between developers and domain experts. This shared language helps elicit the confidence that teams need to continuously deliver innovation. Furthermore, these models map nicely to the notion of bounded, isolated, cloud-native components communicating via event streams. This consistency further instills confidence that the teams have a shared understanding of the functionality.

The preceding diagram is a classic bounded context example from Martin Fowler's blog on the topic (https://martinfowler.com/bliki/BoundedContext.html). It depicts two separate but related bounded contexts: the Sales Context and the Support Context. These contexts are interrelated in that they each have a concept of Product and Customer. Each context has its own definition of a Customer entity and a Product entity and each definition is unique to its context. The only thing that would need to be consistent across the contexts is the identifiers of the instances of these entities as depicted by the interrelationship. One very important thing to note is that there is no unified Customer context and no unified Product context. Each context is bounded and isolated and forms its own bulkhead, such that it can execute and even exist independently. Unfortunately, monolithic thinking would have us create those shared contexts and lead us to create inflexible and un-resilient systems.

Instead, we will integrate the contexts via the domain events. A customer instance may originate in the Sales Context and produce a CustomerCreated event that is consumed by the Support Context. A third context, the Catalog context could be the source of ProductCreated events that are consumed by both the Sales Contexts and Support Contexts, but neither would need to directly query products from the catalog. The Catalog context would only be responsible for the authoring phase of the data life cycle, as we will discuss shortly. Yet another context, such as a Customer Self-Service context, could also produce CustomerCreated events and potentially result in a bi-directional integration with the Sales Context. This brings into question the bounded context that is the official source of record. We will be discussing the idea that the data lake becomes the official source of record. We will cover these event driven patterns throughout the pattern chapters.