Architecture 2025-05-19

Bounded Contexts

Understand bounded contexts in domain-driven design to clarify word meanings, organize responsibilities, and improve system design.

Read in: ja
Bounded Contexts

Overview

There was a challenge to convey to non-developers why contexts organized in a context map are divided in such a way and what the significance of this separation is.

In this article, I will attempt to explain "Bounded Contexts" in a way that is understandable to non-developers.

Being Aware of Context Differences

Even if the same word is used, its meaning can change depending on the context.

For example, consider the word "order."

In the sales department, it may refer to "a request from a customer," while in the warehouse, it could mean "shipping instructions," and in the accounting department, it might refer to "billing data."

Here are some other examples:

Thus, the same word can have different meanings depending on the business or position in which it is used.

The concept of "context" aims to clarify these differences.

What is Context?

Context refers to a grouping of business activities where the meanings of words and rules consistently apply.

In Domain-Driven Design (DDD), this is referred to as a "Bounded Context."

For instance, the meaning of the word "order" can differ based on context as follows:

In this way, the characteristic of context is to "segment" where the meanings and rules of words change in each business.

Why Organize Contexts?

If you proceed with business or design systems without being aware of these contexts, various problems can arise.

Conversely, if you separate and organize contexts, you can gain the following benefits:

In other words, by properly organizing contexts, systems and organizations can benefit in the following ways:

Properly organized contexts lead to improved stability in both systems and organizations.

Example of Context: Orders in an E-Commerce Site

Let’s divide the business related to orders in an e-commerce site into three departments.

Department Meaning of "Order"
Frontend Site Content confirmed by the customer in the cart
Warehouse Operations Instruction data for shipping
Accounting Sales data to be processed for billing

All of these use the word "order," but the content, purpose, and processing involved are completely different.

Ignoring these differences and lumping everything under one term leads to:

This is why it is important to think about "contexts" separately.

Not Just for Developers

Contexts are not something that only developers need to understand.

For example, have you ever wondered about the following questions?

These questions are all closely related to the organization of contexts.

Draw boundaries where the purpose of business and the meanings of words change, and clarify roles and responsibilities within those boundaries.

This perspective is beneficial not only for developers but also for sales, support, planning, and all other professions.

Conclusion

Tags: DDD
Share: 𝕏 Post Facebook Hatena
✏️ View source / Discuss on GitHub
β˜• Support

If you enjoy this blog, consider supporting it. Every bit helps keep it running!


Related Articles