BoundedContext

Martin Fowler

15 January 2014

Bounded Context is a central pattern in Domain-Driven Design. It is the focus of DDD's strategic design section which is all about dealing with large models and teams. DDD deals with large models by dividing them into different Bounded Contexts and being explicit about their interrelationships.

DDD is about designing software based on models of the underlying domain. A model acts as a UbiquitousLanguage to help communication between software developers and domain experts. It also acts as the conceptual foundation for the design of the software itself - how it's broken down into objects or functions. To be effective, a model needs to be unified - that is to be internally consistent so that there are no contradictions within it.

As you try to model a larger domain, it gets progressively harder to build a single unified model. Different groups of people will use subtly different vocabularies in different parts of a large organization. The precision of modeling rapidly runs into this, often leading to a lot of confusion. Typically this confusion focuses on the central concepts of the domain. Early in my career I worked with a electricity utility - here the word "meter" meant subtly different things to different parts of the organization: was it the connection between the grid and a location, the grid and a customer, the physical meter itself (which could be replaced if faulty). These subtle polysemes could be smoothed over in conversation but not in the precise world of computers. Time and time again I see this confusion recur with polysemes like "Customer" and "Product".

In those younger days we were advised to build a unified model of the entire business, but DDD recognizes that we've learned that "total unification of the domain model for a large system will not be feasible or cost-effective" [1]. So instead DDD divides up a large system into Bounded Contexts, each of which can have a unified model - essentially a way of structuring MultipleCanonicalModels.

Bounded Contexts have both unrelated concepts (such as a support ticket only existing in a customer support context) but also share concepts (such as products and customers). Different contexts may have completely different models of common concepts with mechanisms to map between these polysemic concepts for integration. Several DDD patterns explore alternative relationships between contexts.

Various factors draw boundaries between contexts. Usually the dominant one is human culture, since models act as Ubiquitous Language, you need a different model when the language changes. You also find multiple contexts within the same domain context, such as the separation between in-memory and relational database models in a single application. This boundary is set by the different way we represent models.

DDD's strategic design goes on to describe a variety of ways that you have relationships between Bounded Contexts. It's usually worthwhile to depict these using a context map.

Further Reading

The canonical source for DDD is Eric Evans's book. It isn't the easiest read in the software literature, but it's one of those books that amply repays a substantial investment. Bounded Context opens part IV (Strategic Design).

Vaughn Vernon's Implementing Domain-Driven Design focuses on strategic design from the outset. Chapter 2 talks in detail about how a domain is divided into Bounded Contexts and Chapter 3 is the best source on drawing context maps.

I love software books that are both old and still-relevant. One of my favorite such books is William Kent's Data and Reality. I still remember his short description of the polyseme of Oil Wells.

Eric Evans describes how an explicit use of a bounded context can allow teams to graft new functionality in legacy systems using a bubble context. The example illustrates how related Bounded Contexts have similar yet distinct models and how you can map between them.

What are Bounded Contexts and Context Maps in Domain Driven Design?
One of the big problems with approaching a topic like Domain Driven Design is the wealth of new ideas, patterns and terminology you need to get your head around.

This can often mean that a topic is unapproachable or overwhelming because you feel like you are drowning in too much information.

Last week we looked at the What is the Domain Model, what it means and how to think about it as part of an application.

This week we’re going to be looking at two more parts of the Domain Driven Design terminology in Bounded Contexts and Context Maps.

What is the Domain Model?
The Domain Model is the structured knowledge that is related to a specific problem. The Domain Model itself could be code, written prose or a diagram, the medium itself is not really important.

The Domain Model focuses its attention on a specific problem. This constraint forces you to really get at the heart of the problem whilst ignoring everything from the outside world.

This means that the Domain Model will have it’s own internal language that represents the important things that are specific to that one problem.

If you are new to the idea of a Domain Model, I would recommend that you read last week’s post before continuing with this one.

The real world of coexisting Domain Models
The theoretical idea of a Domain Model makes a lot of sense in the world of programming. A Domain Model is the focused knowledge of a problem and so having a clear depiction of the problem and the solution makes your life as a programmer a lot easier.

Having a single model is a noble goal because a single unified model is, in theory, easier to get your head around.

However, in the real world of building applications for businesses, there is never just a single Domain Model. If you were building an application that touches many parts of an existing business, you will likely encounter multiple coexisting Domain Models that will often contradict one another.

For example, in a typical ecommerce web application, the term Product will likely mean something different in the stock system than it does in the catalogue system. This might mean that the two different systems have two different ideas of responsibility for that object, or that the object should have two completely different sets of capabilities.

When objects have multiple different responsibilities for different parts of an application they can become monolithic and difficult to work with. Whats more, when there are multiple developers working on different problems using the same objects, there will inevitably be conflicting requirements and the introduction of unforeseen bugs and inconsistencies.

A Domain Model should be the focused knowledge around a particular problem. This constrains the scope of the Domain Model to a very specific context. When you inevitably encounter these conflicting ideas, it’s time to take a step back from the Domain Model.

What is a Bounded Context?
A Bounded Context is the boundary that surrounds a particular model. This keeps the knowledge inside the boundary consistent whilst ignoring the noise from the outside world.

This is beneficial for a number of reasons.

Firstly you can model the aspects of the problem without having to be concerned with other parts of the business. Using the example from earlier, a Product object within the stock system only needs to be concerned with the methods and properties of that single system, rather than any other business concern that happens to fit on an object called Product.

Secondly the terminology within a Bounded Context can have single, clear definition that accurately describe the problem at hand. Different departments across a company will usually have slightly different ideas and definitions of similar terms, but this can often derail a project through a lack of clarity and understanding when terms are mixed.

What is a Context Map?
When you start to think about the various subsystems of an application as individual Bounded Contexts, you can lose sight of the global view of the business as a whole.

It is inevitable that the various Bounded Contexts of an application will need to communicate or share data between each other.

A Context Map is the global view of the application as a whole. Each Bounded Context fits within the Context Map to show how they should communicate amongst each other and how data should be shared.

Conclusion
Bounded Context are a very important modelling tool when it comes to Domain Driven Development.

Bounded Contexts allow you to split a big problem into much smaller problems so you can focus on particular aspects of the application whilst ignoring everything else.

This allows you to form a consistent language around that specific problem so that everyone has a clear definition of each of the important terms.

Typically there will be certain objects in a web application that have different definitions in different context of the application. By splitting the application into Bounded Context, you ensure that the lines between each context are clearly defined so that the terminology around ideas and concepts of the application are clearly understood.

However when you focus on the minutia, you can often lose sight of the bigger picture of the application. A Context Map should show where each Bounded Context sits in relation to the others. There is often a lot of important information in the associations of Bounded Contexts and so a Context Map ensures that knowledge does not fall through the gaps.