Bounded Context

A Bounded Context is the central pattern in Domain-Driven Design for managing complexity. It defines the strict limits within which a specific model applies, providing a robust foundation for the evolution of business software. On this page, we explore how to define, map, and implement Bounded Contexts in modern architectures.

A typical business software is built around a specific need. If we’ve implemented it well, it will solve a problem, make some users happy, and also make them more willing to ask for more. Great! Now our software solves two problems instead of one, and the story can repeat. Unfortunately, with every new functionality, we progressively lose the ability to change our software. It’s a subtle and gradual process of increasing complexity in the codebase, accompanied by an increase in responsibility towards the business: the larger the numbers, the higher the risk involved in making changes. Technically, changes are still possible, but business-wise, we tend to procrastinate them.

Doing things right from the beginning isn’t a viable strategy. It clashes with a simple fact – we wrote the original code with significantly less information than we have today. We learn over time, and now we could probably write that code a lot better, but we are less confident in making the necessary changes. Codebases born with the best intentions often end up bloated and slow down the business growth they were intended to support.

Enter Bounded Contexts

Bounded Context is the missing abstraction that can give structure to young codebases and flexibility to mature ones. The original definition from Eric Evans’ Domain-Driven Design: Tackling Complexity at the Heart of Software is:

A Bounded Context is the limit of applicability of a model.

The underlying idea is that models are not replicas of the real world in a programming language; they are sets of selected abstractions that work together to solve a business problem. Models are not replicas of reality, but they serve a purpose, and that purpose should drive their design.

Selection is key here: we are not aiming for completeness or accuracy. We design solutions tailored to a single purpose. Business software is too complex to have a single purpose, so we need more models. A bounded context is our way to keep unnecessary complexity outside our model.

This implies a fundamental responsibility for modelling practitioners: it’s our duty to define boundaries because, while purpose might still be a fuzzy concept, we can’t build reliable software on top of a fuzzy and ambiguous model.

Focusing on a single purpose also provides space for optimisation. We can focus on our purpose without trade-offs with the nearby models. While we might need translations between models, within our bounded context, we are free to pursue the best implementation for our current problem. Addressing a different purpose should be the responsibility of a different model.

Bounded Context is a fuzzy idea

Software developers like precision, clarity and taxonomies—square boxes fitting inside square boxes. Bounded Contexts aren’t that: they are a liminal concept that can be viewed in different ways. They don’t only shape the software, but also the ecosystem involved in building it.

Let’s examine this idea from various perspectives.

Bounded Contexts as a unit of language consistency

Language precision is vital to developing robust and unambiguous software models. Domain-Driven Design introduces the concept of Ubiquitous Language to describe a precise modelling language shared among the stakeholders of a software project. A conversational language with the precision of a software model, and a software model with the expressiveness of conversational language. No ambiguities and no translation: every term has only one precise meaning.

Unfortunately, we know that this precision doesn’t scale. People will mention invoices without specifying whether they are received or issued. In Sales, we can negotiate an order, apply discounts or tweak the payment terms, but once signed, it becomes immutable.

In a single Bounded Context, there is no ambiguity. The context constrains the meaning of the word to only one valid interpretation in the current model.

Data versus behaviour

It’s worth mentioning that different modelling perspectives are often pulling in competing directions: data-centric modelling emphasises data structures. It will typically pull towards shared models, while behaviour will give you insights leading to model separation.

Looking strictly at the signals coming from the language, nouns will nudge your models towards large shared entities, while verbs will tend to cluster around a shared purpose. Exploring a domain with EventStorming is a brilliant way to discover signals that lead to independent models.

Bounded Context as an opportunity for model simplicity

With a clear purpose in mind, we can remove redundancies from our model, often realising that we aren’t doing rocket science, and that a simpler, sometimes minimalistic, abstraction is what we need. In other words, models are defined by what should be part of the model, but also by what shouldn’t.

The conversation example on the left can lead us to introduce foreign concepts into our local forecast model, and with them, the possibility of coupling. Distilling models towards cleaner abstractions allow sharper and simpler models. An Income Expectation can be related to an Invoice from billing, but the Expected Payment Date is only loosely coupled to the invoice’s Due Date. A customer in financial trouble, will expose the drawbacks of a coupled model. You are entitled to receive a given amount, but it’s pointless to expect it.

Simpler models are more robust and easier to test, offering an opportunity to achieve more by composing simple and robust abstractions into more sophisticated services.

Pushing complexity aside

We can achieve model simplicity also by keeping the external complexity out of the door. Anti-Corruption Layers are a popular way to protect our model, keeping unnecessary abstractions behind the door.

The quality of a model can depend on how much complexity we can ignore within our bounded context.

An opportunity for specialised architectural styles

Once the purpose of our model is clear, we can pursue it without trade-offs. Some approaches, such as functional programming, fit better certain portions of our system. We might adopt an architectural style that better suits the problem at hand without sharing the same approach with the rest of the organisation. Event Sourcing works well with transactional models, but can quickly become overkill with more malleable draft models.

The implementation style and working agreements can be local to a Bounded Context. Capturing stakeholders’ needs with BDD scenarios can be vital in some cases and burdensome somewhere else. The responsible team would be in charge of the decision.

An opportunity for a specialised architecture doesn’t mean anarchy. In fact, it means negotiating a contract with the neighbouring models, while assuming accountability for your implementation.

A foundation for distributed systems

Bounded Contexts are not a recent idea; they originated in the early 2000s. The rise of Microservices made them popular because a distributed system can go astray very easily without proper boundaries in place, and bounded contexts provided precisely the missing abstraction.

However, while Microservices need Bounded Contexts badly, there is only a partial overlap between the two ideas (you may want to read our blog post: About Bounded Contexts and Microservices on the matter).

In practice, you can leverage logical model decomposition in a modularised monolith and transition to a distributed system only when needed.

Organisational clarity

A Bounded Context is typically the responsibility of a single team: the size of the model is usually small enough, and having multiple teams work on the same model without sharing the same design approach is generally a recipe for disaster. Imagine having the same kitchen for a gourmet restaurant and a burger place.

A clear purpose often means talking with fewer stakeholders, usually coming from the same organisational area. Fewer stakeholders mean fewer coordination meetings and less need for consensus across departments. Reaching an agreement can be extremely expensive in some organisations, and well-defined boundaries mean that you can deliver new features with minimal coordination effort. If your new functionalities require massive coordination, there’s probably something wrong with your architecture.

Bounded Contexts as a virtuous feedback cycle

A single team with clear responsibility over a business functionality is the perfect setting for a virtuous quality cycle. If we protected our boundaries, then there should be no targets for the blame game: a bug in our software comes from our team.

And a good team uses it as an opportunity for deeper insight, leading to a small extra modelling session if we uncover a new business scenario, or refactoring around a better abstraction if the bug reveals some shortcomings in our model.

If you’re a fan of Daniel Pink’s autonomy, mastery and purpose, you might recognise that a Bounded Context provides the perfect environment for a team to perform at their top. If you’re not, you may want to check this video or the book Drive.

Bounded Contexts as a pillar for strategic learning

When writing business software, we continually learn. As software specialists, we are first learning the complexity of a domain we didn’t know. Then, in competitive markets, we follow (or anticipate) the new directions of the business, learning new things, and discovering new opportunities to become more effective.

When a business opportunity materialises, bounded contexts provide a robust foundation to shorten the release cycle. New model insights can be delivered faster because we’ll keep the ripple effect to a minimum.

More interestingly, the confidence derived from clean, robust models will prompt your team to conduct more experiments, eventually becoming a leading source of business opportunities. Coupling is the invisible force holding you back.

The switch is from “It’s going to be a mess.” to “Let’s give it a try!”

---

In Practice

Extract Purpose

If you’re starting from scratch, you may want to run a Big Picture EventStorming to detect signals about the boundaries in your business domain. The workshop should give you enough information to start sketching a Context Map. If you are in a brownfield scenario, you may want to sketch two maps: one Brownfield Context Map for the current state, and one Greenfield Context Map for the desired target state.

With a greenfield mindset, you can start extracting and sharpening the purpose of your Bounded Context. This is a linguistic exercise to condense a few clear paragraphs that describe what happens within your bounded context, and the key abstractions needed.

In a brownfield, this can feel like a waste of time: a Big Ball of Mud will have a very wide and incoherent purpose. That’s a signal that your boundaries need some refinement.

Make Boundaries Explicit

Bounded Contexts will have to talk to each other. Pivotal Events can be a great source of information to sketch a communication pattern, but Events aren’t the only way to communicate. Showing the formats for incoming and outgoing information can help make the boundaries concrete.

Enforce Private Persistence

Every Bounded Context should manage its own data. A shared database can be a backdoor for a script that violates the integrity checks in our domain model, or an impediment to running local experiments and discovering new abstractions. But we have to keep in mind that Bounded Contexts should be autonomous. An e-commerce might need the current version of the Product Catalogue, not the entire set of data in the Catalogue Bounded Context.

Write minimal documentation

Once you see the new structure, you need reference documentation to be shared across teams. Write with the reader’s perspective in mind. Documentation is pointless when not consumed. Often, it’s not about filling every space in a form, but about having an accessible space where the most relevant information is available.

Colocated teams may enjoy a shared physical map as an information radiator. Remote teams should make the shared artefact as easily accessible as possible.

Provide a Structured Glossary

Language is a tricky beast; don’t fall into the trap of providing one flat Dictionary page. Terms have a meaning inside a Bounded Context. Make sure a Bounded Context is a first-class citizen in your documentation, not an afterthought.

---

F.A.Q.

Is Bounded Context the same as a domain?

No. But to understand the difference, we need to be clear about what a “Domain” is. In Domain-Driven Design, the term means: “A sphere of knowledge, an area of expertise”, emphasising the need to understand the complexity of the problem space. In Domain-Driven Design, a Domain is what we need to learn, while a bounded context is the set of abstractions used to model a solution.

• Domain: “Our company has a network of external collaborators, who can provide services as trainers or as consultants, depending on the situation.”
• Bounded Context: “In Partnerships, a Partner can have one or more  Role, every Role should be associated with a Deal. In Delivery, every Collaborator is associated with a Deal, that we’ll use to calculate the BillableAmount. ”

But the term “Domain” isn’t used in the precise DDD style only. Many refer to a Domain as a group of key entities to model a problem space, with little distinction between the model and its persistence on the database. This can be a slippery slope, because Bounded Contexts tend to be separated, driven by the model’s purpose, while data-centric domains tend to be more coupled. This ambiguity frequently leads to bad model boundaries and the distributed monolith antipattern.

Can Bounded Contexts be used with different architectural styles?

Yes, the purpose defines what may be the optimal architectural style to support the model. A common approach is to have a more CRUD-style model to support the draft side of a key entity lifecycle, and a CQRS/ES implementation for the more transactional portion of the system.