What is a Bounded Context?
Attempting to create a single universal language and model for the entirety of the organisation’s software systems, is doomed to fail. That's why Bounded Contexts are so useful.
One of the real innovations of Domain-Driven Design is the notion of Bounded Contexts.
Since the early years of software design, we've been looking at modularisation as a way to manage complexity. This modularisation usually happens at two levels:
Technical separation: we split code into modules or components; libraries and packages; version control repositories; apps, services, and microservices; and any kind of independently deployable units. This separation often also follows technologies: e.g. Javascript frontend with a Ruby backend, or a C# service delegates the machine learning responsibilities to a Python application.
Domain separation: We look at the business domains, and split the software according to pre-existing boundaries in the business, for example, Accounting, Sales, Shipping.
In practice, separation also happens for organisational reasons, but we'll dive into this in a future post.
Bounded Contexts add a third axis for separation. While many authors make no distinction between domain boundaries and Bounded Context boundaries, they serve a different purpose. It turns out that this form of separation is a much more pragmatic way of managing the complexity of software systems. So what is a Bounded Context?
The Problem
When we are building any software system, we operate in mental models of how the business domain works and how our system works, and we have a language to talk about it. Domain-Driven Design puts a lot of emphasis on making these models and languages explicit. By encouraging collaboration between engineering and domain experts, we make sure these models and languages are shared.
In a large complex organisation, you’ll find:
ambiguity, such as words having different meanings in different areas
variation in business rules and their interpretations
domain models and data models that cover similar domain concepts but that are structured differently
business processes that are implemented slightly differently in different areas
Attempting to create a single universal language and model for the entirety of the organisation’s software systems, is doomed to fail. Nobody can understand everything, so it’s impossible to create a consistent model for everything.
Understandability boundaries
A great way to form an intuition for Bounded Contexts is to think of them as understandability boundaries.
We're drawing a line, and within this line, the language and the model is consistent, cohesive and well-understood. Ideally together, we can solve our problem as we can understand everything within this boundary. The language and model need to be together because in order to understand A, we need to understand B and C, and to understand B we need to understand A and C, so they logically want to be grouped together.
Importantly we draw these boundaries so we can stay within them. Within it, we have a very consistent language with no ambiguity, we have consistent business rules, we have a model, but outside this boundary, we're not guaranteeing that. This allows us to have ambiguity across contexts but not within it.
This is fundamentally a complexity management technique for the team. Computers don't care about our mental models and understandability boundaries we set. Instead it's for us to better understand the system, and breaking the system into smaller bounded contexts benefits us when we’re building in complex environments.
Drawing bounded contexts is the craft of the software designer
There is an art to drawing a valuable bounded context. Too small and it goes wrong because to understand one thing, you still need to understand what’s in the other boundaries. So the art of system design is to figure out which things make sense to understand together and which things don't depend on each other.
Of course the different systems and bounded contexts need to communicate, so you will need a protocol to follow to communicate, but if there's lots of communication and lots of language needed to understand each other, then most likely, the boundary isn't very good.
It's therefore a line around the language and the model first. It's not necessarily a system boundary. You could have a bounded context that is spread over two systems or services, or you could have a single system with multiple bounded contexts. It's really a linguistic boundary, a semantic boundary, an understandability boundary; a way to group things that can be understood together and that need to be understood together. That's the ideal, but pragmatically there might be other reasons for drawing the boundaries differently. That's the trade-off that the designer needs to make.
The essence of the design is to understand the purpose of the system, and to understand the resources and the constraints within the system, and to then make the best design decisions based on limited knowledge. Bounded contexts therefore are a tool to help us deal with complexity.
Where you can learn more: