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.

  • sapiensworks.com/blog/post/2012/04/17/… Commented Apr 30, 2014 at 17:04
  • 2
    That post doesn't really make the definition clear, at least for me. It discusses the idea of bounded contexts as they may apply organizationally, but it never really bridges this back to software development.
    – Michael
    Commented Apr 30, 2014 at 18:31
  • 1
    OK. Well, although I'm not a DDD expert, I did find this description from Microsoft useful (in the Introduction paragraph): msdn.microsoft.com/en-us/library/jj591572.aspx. It says:... Commented Apr 30, 2014 at 18:34
  • 1
    Bounded contexts are autonomous components, with their own domain models and their own ubiquitous language. They should not have any dependencies on each other at run time and should be capable of running in isolation. However they are a part of the same overall system and do need to exchange data with one another... Commented Apr 30, 2014 at 18:35
  • 1
    ...If you are implementing the CQRS pattern in a bounded context, you should use events for this type of communication: your bounded context can respond to events that are raised outside of the bounded context, and your bounded context can publish events that other bounded contexts may subscribe to. Events, enable you to maintain the loose coupling between your bounded contexts. Commented Apr 30, 2014 at 18:36

3 Answers 3


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.

  • 1
    So, in an ideal world, there would be a 1-to-1 relationship between subdomains and bounded contexts? (Understanding, obviously, that what is ideal and what is true differ).
    – Michael
    Commented May 5, 2014 at 20:59
  • 2
    Not necessarily: the key thing is that a BC overlapping many subdomains is a bad smell. Well... it's not bounded. In DDD terms a model should be perfectly fit to its purpose, and different subdomains have different purposes (and probably even different bosses with different goals). But within the same subdomain, different BC may exists for different reasons. Web and mobile app might be the case, or different models for planning or execution.
    – ZioBrando
    Commented May 5, 2014 at 21:53
  • But the key thing is to understand that there are two problem families: 1) reading the existing context (where you can only accept and categorise the existing models and collaborations), 2) designing the right software given the existing constraints, thus imposing context boundaries between small, purpose oriented models. In the second scenario you won't intentionally overlap subdomain borders. ...in general, looking for perfect software in an non-perfect organisation might be hard stuff. But solving those inconsistencies might be worth the effort.
    – ZioBrando
    Commented May 5, 2014 at 22:03

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.

  • 1
    So it's a fence around a subdomain, basically. Commented Apr 30, 2014 at 21:30
  • 1
    Yes. As far as I can see it. It's a fence.
    – JW01
    Commented Apr 30, 2014 at 21:36

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.