What are Bounded Contexts and Context Maps in Domain Driven Design?

Nov 19, 2014

Table of contents:

1. What is the Domain Model?
2. The real world of coexisting Domain Models
3. What is a Bounded Context?
4. What is a Context Map?
5. Conclusion

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.