In simple words, it is part of the system in which we solve business problems. Technically speaking, it could be a microservice code repository, in which we write code that implements business requirements.

‘Bounded context’ is a context with emphasis on the boundary of the context, therefore it is called a bounded. If you do not know what the context is here is the explanation One word many meanings – context intro.

Bounded context is one of the most important concepts of DDD and is difficult to understand. Moreover, I’m sure there is no one clear and simple definition of a bounded context, so let’s go step by step to understand it:

• is a linguistic (language) boundary

Bounded context is a linguistic (specific language) boundary. Let’s clarify that on e-commerce example. The e-commerce system consists of many parts, but we focus on two: the product catalog and the warehouse. When you talk to the people/domain experts who work with the product catalog and in the warehouse, they use different language and different terms:

They talk about the same thing – the product. When you ask them what a product is, they give different answers:

For the warehousemen, the product is a package, and he doesn’t even know what’s in the package. They perceive the product from their specific perspective. This particular perspective is a context/bounded context:

• contains model

At the beginning of the post, I wrote that bounded context contains code that implements business requirements. Yes, this code that solves/fulfills business needs is a model. We call it a model because it is a specific solution in the context of the problem. If you don’t know or feel what a model is, read here: What is a model?

Models (ultimately classes when using an object-oriented paradigm) that fulfil above requirements could look like this:

We have models that solve problems in particular contexts. Outside the context the model Package makes no sense, for example, Package is useless in a product catalog context because it does not have the required properties and behaviors. Again the ‘bounded’ is important because the model is only valid inside the boundary of the context.

We could even name the models/classes the same:

and that’s perfectly fine as context gives meaning. When we talk about a product in the context of a warehouse, we know it means a package.

• is a solution

Bounded context belongs to the solution space. It is a subsystem, component, or module, whatever you want to call it. Technically, it is a package, maven module or repository – a container for code, especially our models/classes:

Bounded context has a strict API that communicates with other bounded contexts and does not share models with others. These are general concepts for well-designed modules.

• is not a deployment model

Bounded context could be implemented and deployed as microservice or many microservices, but this does not matter. Bounded context concept is a logical thing – part of the software, as you see in point above. It is not deployment model.

Definitions

Let’s looks at some definitions of the bounded context. Now you should know what they mean:

A bounded context is a boundary for a model expressed in a consistent language tailored around a specific purpose. source

“bounded context is a boundary for a model” – we explained that:

“model expressed in a consistent language“:

A bounded context is a defined part of software where particular terms, definitions and rules apply in a consistent way <source>

“defined part of software“:

“where particular terms, definitions and rules apply in a consistent way”

Why (bounded) context is important?

In one word, contexts are crucial to build great IT software/systems in bigger systems. Let’s see why Wrong boundaries – a way to hell.

You saw in the example above that we create two models. It wouldn’t be easier if we create one model/class with all the properties and use it everywhere? No. That model has and causes many negative consequences. Read more here: All-in-one model. Without the contexts, or when we do not take contexts into account, we create a model that has to fulfill all contexts, thus creating an all-in-one big model.

We need contexts to build a proper, tailored solutions/models. Read more here: Model in the context

Where do the bounded contexts come from?

This is the hardest part, so maybe we’ll skip it 🙂 Just kidding. Here is the great practical presentation 18 Heuristics to Discover your Contexts Boundaries. Many heuristics apply also to discovering subdomains How to discover (sub)domains because in an ideal world bounded context = subdomain. I think it’s wise to start with subdomains. Later, as you delve into the solution, you will verify your bounded contexts. An especially useful technique is process-level event storming, where you can validate your domains and discover/define the bounded contexts.