Subdomains vs. Bounded Contexts: similar boundaries, different purposes

We have learned a lot about the problem space and how to gain a better understanding of the business our solution needs to support. Now it's time to move to the solution and its design!

What is a Bounded Context?

A Bounded Context defines the boundaries within which a particular model and its ubiquitous language apply. The model is designed to address a particular problem or a set of related problems. A well-defined Bounded Context keeps the model focused on what is relevant, leaving aside details that are not needed to understand the problem and implement the solution.

Bounded Context vs. Subdomains

Bounded Contexts and subdomains have something important in common: both establish boundaries. However, they serve different purposes.

Subdomains divide the business domain into smaller parts to help us understand the problems, requirements, and knowledge needed to address them. Bounded Contexts define the boundaries within which we develop and use models to solve those problems.

Both subdomains and Bounded Contexts need a consistent language within their boundaries. When exploring a subdomain, we discover the business concepts and terminology used by domain experts. When designing a Bounded Context, we establish the language used by the model to represent the problems it solves. These languages can overlap, differ, or even be identical. What matters is that the meaning of terms is clear and consistent within each boundary.

Subdomains define essential complexity

Subdomains help us identify and explore the essential complexity of the business problems we need to understand and solve. This is where domain experts operate, and where we learn about the concepts, rules, and definitions they use.

The goal is to understand what makes the business problem challenging before deciding how to implement a solution. Without this understanding, we risk designing a solution around our assumptions rather than the actual needs of the business.

Bounded Contexts define model boundaries

A Bounded Context defines the boundaries within which a model applies to the problems we want to solve. As I wrote recently, all models are wrong - they are simplified representations of reality, and their value depends on whether they serve their intended purpose.

Does the model contain enough detail? Does it include too much information? Does it represent the rules and concepts required to solve the problems within its scope?

These questions help us assess whether the model is useful. The boundaries of a Bounded Context also help us determine which concepts and rules belong in that model and which should be handled elsewhere.

Implementation introduces complexity and trade-offs

A model must eventually be implemented, and the implementation introduces its own challenges. Some complexity comes from the business problem itself; other complexity results from the decisions we make when designing and implementing the solution.

Accidental complexity is complexity introduced by the way we choose to solve a problem rather than by the problem itself. Not every implementation challenge is accidental: some complexity is an unavoidable consequence of the requirements, constraints, or characteristics of the chosen solution.

Defining Bounded Context boundaries does not automatically introduce accidental complexity. However, those decisions influence the complexity of the resulting solution. For example, splitting a model into multiple contexts may improve separation of responsibilities, but it can also introduce integration, communication, and data consistency challenges. Keeping everything in one context may simplify those interactions, but it can create a model with too many responsibilities.

The cost of these trade-offs depends on many factors: how many people will work on the solution, their experience, what they know, the technologies the company supports, and the operational constraints they face. That's why different teams may arrive at different solutions to the same problem. The important thing is to understand the consequences of those decisions rather than assume that one design is universally correct.

Example

At first glance, the differences between subdomains and Bounded Contexts, as well as those between the problem and solution spaces, might seem subtle. To make them easier to understand, let's walk through an example from the training center domain.

A training center needs to manage trainers' skills. According to the requirements, it must maintain a Skills Database - a comprehensive inventory of each trainer's skills. Based on our current domain discovery, this capability could be part of the Education core domain. Alternatively, we might identify Competency Management as a separate subdomain because it represents a distinct set of business problems and responsibilities.

Our problem space is Competency Management. What problems do we need to address? Here are a few questions a training center needs to answer:

P1. What competencies are relevant to us?
P2. Does someone actually possess a particular competency?
P3. What competencies does each trainer possess?
P4. Which competencies are currently available across our trainers, and which competencies will we need to deliver our planned training courses?

Within this subdomain, domain experts help us understand how these problems are addressed, what rules and conditions apply, and which terms we should use to describe everything accurately. In other words, they help us discover the ubiquitous language used to describe this part of the business.

Once we understand the problem space, we can start designing the solution. We need to decide which models to build and where their boundaries should lie. There is no single correct design: different arrangements can solve the same business problems, but they come with different responsibilities and trade-offs.

What options do we have?

1. Keep the Bounded Context boundaries aligned with the subdomain boundaries. We can address all four questions within one context, provided the resulting model remains cohesive and its responsibilities are manageable. The fact that the language is consistent within the subdomain helps us understand the business, but it doesn't automatically mean that one model is the best solution.
2. Create a separate Bounded Context for each identified problem. Each context would focus on one question. For example, one context could define which competencies are relevant to the training company, while another could assess whether a particular trainer possesses a competency. This approach separates responsibilities, but it may also introduce duplicated concepts and additional communication between contexts. It makes sense only if the benefits of that separation justify the costs.
3. Group related problems into a smaller number of Bounded Contexts. For example, P1 focuses on defining competencies, so it could belong to BC1, the Competency Catalog. P2 and P3 focus on assessing and tracking trainers' competencies, so they could belong to BC2, Trainer Competencies. P4 could belong to a separate bounded context focused on Training Planning, where the organization defines the competencies required to deliver planned courses and identifies gaps.
   In this design, BC1 defines what a competency means, BC2 records and evaluates trainers' competencies, and the Training Planning context determines which competencies the organization needs. These contexts may use related concepts, but each model serves a different responsibility.

There are also many other factors that can influence the boundaries of a Bounded Context within the solution space. For example:

• Some problems may be solved using LLMs, while others may require deterministic rules or other approaches.
• Some use cases will be heavily used, while others will be relatively rare.
• Some contexts may focus on reading data with only occasional modifications, while others may handle frequent updates.
• Some responsibilities may need to evolve independently, while others are closely connected and benefit from being handled together.
• Some boundaries may simplify development but introduce costly integration or data consistency challenges.

These factors don't provide a formula for defining Bounded Context boundaries. Instead, they help us evaluate the trade-offs and decide which design best supports the business problems we need to solve. We've only scratched the surface, but don't worry - we'll explore it in much greater depth in the next articles.

Summary

Subdomains and Bounded Contexts are related, but they serve different purposes.

Subdomains help us understand the business problems, the essential complexity involved, and the knowledge we need to acquire from domain experts. Bounded Contexts define the boundaries within which we build models to address those problems.

Understanding this distinction helps us move from discovering the business domain to making deliberate architectural decisions.