What, in reference to DDD, is a bounded context?

Question

When working through the book "Implementing Domain Driven Design" by Vaughn Vernon, I have been unable to gain a good grasp on what a bounded context actually is.

The book defines a bounded context as "a conceptual boundary where a domain model is applicable. It provides Ubiquitous Language that is spoken by the team and expressed in its carefully designed software model" (the "Guide to this Book" prefacing section). This definition would make it sound as though a bounded context is the model and language of a subdomain, where that subdomain may happen to be the core domain (which seems like it ought to be referred to as a "core subdomain", but that is another discussion...). This still leaves some ambiguity as to what a bounded context provides. Is it a grouping of one or more subdomains? If only one subdomain corresponds to a bounded context, what is the bounded context actually telling us?

Chapter 3 of the same book, however, refers to the integration techniques between bounded contexts. This, however, would seem to imply that the bounded contexts are actually software systems or artefacts of some variety.

Martin Fowler briefly discusses the idea of a bounded context (http://martinfowler.com/bliki/BoundedContext.html), but does not really clarify the issue.

At the end of the day, what is a bounded context? Is it a grouping of subdomains? The model and language for a subdomain? The implementation of a subdomain? Without these answers, it seems rather difficult to understand how to decompose a real-life problem space into bounded contexts.

Answer 1

Bounded Contexts and Subdomains exist at different levels.

A Subdomain is a portion of the problem space, it's a natural partitioning of the system, often reflecting the structure of the organisation. So logistics and operations might be separated from invoicing & billing. Eric differentiates core, supporting and generic subdomains according to their business relevance in the given scenario.

Contexts are portions of the solutions space. They're models. It would be a good thing to have them, reflect the domains-subdomains partitioning ...but life isn't always that easy. And you might have bloated legacy domain encompassing everything, or more context in the same subdomain (i.e. old legacy app the replacement app somebody is building).

To have a Bounded Context you need to have a model, and an explicit boundary around it. Exactly what's missing in many data-driven application that use databases to share data.

Another - orthogonal - way to see it may be the following. Ubiquitous Language, the special condition where every term has a single unambiguous definition, doesn't scale. The more you enlarge it, the more ambiguity creeps in. If you want to achieve precise, unambiguous models, you need to make their boundaries explicit, and speak many little Ubiquitous Languages, each one within a single Bounded Context, with a well defined purpose.

Answer 2

Domain Driven Design techniques are used to help us make models of the world that we live in. These models exist as ideas in the minds of the people involved in a project.

Because telepathy is still in its infancy, these ideas are communicated between people using words and phrases.

Words and phrases can be ambiguous at the best of times. To help us reduce ambiguity, we use 'context' to clarify their meaning.

When people get deeply immersed in a software project that spans years, they seem to forget the context from which came the ideas that turned into the words which turned into the variable names that were baked into the code.

Newbies arrive to the project and start using and consuming its language. Perhaps they are users, perhaps they are developers. If there is no context provided to them, they will come up with their own context (and, therefore, meaning) from their own life experience.

This newly applied context will guide how new developers refactor or develop the code. If they applied the wrong context, they will refactor and develop the code in, perhaps ever-so-slightly, the wrong direction. Wrong directions, however slight, can cause much bigger problems down the line.

As I see it, a 'bounded context' is merely a 'clarified context' that is handed to project newbies so they don't apply their own arbitrary context to taint our, beautifully honed, model.

It is some explicit acknowledgement, by the team, that this phrase, in this part of the project means exactly this thing (and not, as you might well think, that thing).

Just as it is a good idea to mark the boundaries between your garden and your neighbour's garden. You specify the boundary explicitly so that you don't get angry when they start digging a flower bed on your perfectly manicured lawn.

That is it. It is a very simple idea which is so important that lots has been written about it.

So yes. A bounded context is quite literally a boundary, a 'fence', that distinguishes between the context of one subdomain from the context of another subdomain in a project.

The model and language of a subdomain are isolated from other model and languages to avoid ambiguities in meaning.

But, yes. The world is not so simple.

You and the team have to be rigorous in adhering to the defined context. It is really easy to be lazy and re-imagine the context to cut corners during software construction.

Also, things interact with other things and bounded contexts need to interact with each other too. So, there are various patterns to describe how those interactions occur. See Eric Evan's book Domain Driven Design Chapter 14 for these various patterns: Shared Kernel, Customer Supplier, Conformist, Anticorruption Layer, Separate Ways, Open Host Service, Published Language.

Answer 3

Basically, Bounded context defines some tangible boundaries of applicability of some sub-domain. It is some abstract area where a certain sub-domain makes sense, while the others don’t. So this can be a talk, a presentation, a code project with physical boundaries defined by the artifact.

In different situations I use three different perspectives, or metaphors of the Bounded Context concept.

From the run-time perspective, it represents logical boundaries, defined by contract of a service where the model is implemented. The contract can be represented as this service’s API or a set of events it publishes and consumes. So from this perspective Bounded context has nothing to do with physical boundaries.

From the perspective of a domain expert, bounded context is an area where certain business-processes are implemented, the certain ubiquitous language is applied, and a certain terms make a clear sense, while the others don’t. So it could be a rectangle drawn on a sheet of paper or a whiteboard.

For a software developer, i.e., from the static code perspective, a bounded context represents a way I designed my models around corresponding sub-domains; that is, it's your codebase. More specifically, it's a project (or projects) in your IDE. That’s why it is said that bounded contexts belong to a Solution space.

I really like this example of the Bounded Context concept.

Another important question (if not the most important one) is how to identify bounded contexts. If you'd do that incorrectly, you'll end up with chatty, unmaintainable and tightly coupled services, also known as distributed monolith.