03 | Bounded context: a sharp tool for defining domain boundaries

This article focuses on "bounded context".

In the process of DDD domain modeling and system construction, there are many participants, including domain experts, product managers, project managers, architects, development managers, and test managers. For the same domain knowledge, different participating roles may have different understandings, so there will be obstacles in communication, what should I do? Therefore, the two important concepts of "universal language" and "bounded context" appeared in DDD.

The two complement each other, the common language defines the context meaning, and the bounded context defines the domain boundary to ensure that each context meaning has a unique meaning within its specific boundary, and the domain model exists within this boundary. Do you feel that such a description is abstract? It doesn't matter, I will explain it in detail next.

Before that, I would like to ask you to look at these two questions, which are also the core of today's content.

1. Why is the concept of bounded context proposed (that is to say, in addition to solving the general reason of communication barriers, are there more specific reasons)?
2. What is the role and significance of bounded context in microservice design?

​​​​What is a lingua franca?

In order to better understand the bounded context and answer these two questions, let's start with the general language.

How to understand the concept of universal language? During the event storm, the common language is the language that can simply, clearly and accurately describe the business meaning and rules reached through team communication. That is to say, the common language is the unified language of the team. No matter what role you play in the team, you use a unified language to communicate in the software life cycle in the same field.

Then, the value of a common language is clear. It can solve the problem of communication barriers and enable domain experts and developers to work together to ensure the correct expression of business needs.

However, the understanding of this concept is not enough here.

The common language contains terminology and use-case scenarios and is directly reflected in the code. Nouns in common language can name domain objects, such as commodities, orders, etc., corresponding to entity objects; while verbs represent an action or event, such as an order for a commodity, payment for an order, etc., corresponding to domain events or commands.

A common language runs through the entire design process of DDD. As a unified language formed by project team communication and negotiation, based on it, you can develop more readable code and accurately translate business requirements into code design.

Let's look at a picture below, which describes the complete process from the event storm to establish a common language to domain object design and code implementation.

1. In the process of event storm, domain experts will build domain models together with designers and developers, and common business terms and user stories will be formed in the process of domain modeling. Event storming is also a process for the project team to unify the language.
2. Through user story analysis, domain objects will be formed one by one. These domain objects correspond to the business objects of the domain model. Each business object and domain object has common terms and terms, and they are mapped one by one.
3. The microservice code model comes from the domain model, and the code objects of each code model correspond to the domain objects one by one.

Here I will share with you another piece of experience. I use it often and it is very effective. During the design process, we can use some tables to record the domain objects and their properties generated during the event storm and microservice design process. For example, the location, attributes, dependencies, and mapping relationship between domain objects and code model objects in the DDD layered architecture.

The following is part of the data of a microservice design example. The terms in the table are the common language that the project team agrees during the event storm and can be used for internal communication within the team. In this table, we can see that all domain objects and their attributes are recorded during the DDD analysis process. In addition to the domain objects of DDD, we also record the code objects corresponding to the domain objects during the microservice design process. , and map them one by one. 

At this point, I want to emphasize it again. Every link in the DDD analysis and design process needs to ensure the unification of terms in the bounded context. When designing the code model, it is necessary to establish a one-to-one mapping between domain objects and code objects, so as to ensure the consistency between the business model and the code model. Realize the unification of business language and code language.

If you do this, that is, establish the mapping relationship between domain objects and code objects, you can guide software developers to complete microservice development according to the design documents accurately. Even business personnel who are not familiar with the code can quickly find the location of the code.

What is a bounded context?

What is the bounded context just mentioned for?

We know that a language has its semantic environment, and a common language also has its context. In order to avoid the ambiguity of the same concept or semantics in different contexts, DDD puts forward the concept of "bounded context" in strategic design, which is used to determine the domain boundary where the semantics are located.

We can break down a bounded context into two words: bounded and context. Boundaries are domain boundaries, and contexts are semantic environments. Through the bounded context of the domain, we can communicate with a unified language within a unified domain boundary.

To sum it up, I think the definition of bounded context is: it is used to encapsulate general language and domain objects, provide a context environment, and ensure that some terms, business-related objects, etc. (common language) in the domain have an exact meaning without ambiguity sex. This boundary defines the applicable scope of the model, so that all team members can clearly know what should be implemented in the model and what should not be implemented in the model.

Further understanding of bounded context

We can further understand this concept through some examples. Don't underestimate it. A thorough understanding will lay a solid foundation for you to practice DDD later.

They all say that Chinese is a very rich language, and the same sentence will have different meanings in different time and space and in different backgrounds. There is an example you should have heard.

On a bright morning, the child got up and asked his mother: "How many clothes should I wear today?" The mother replied: "As much as I can wear!"

So is it more or less?

If there is no specific semantic environment, it is really not easy to understand. However, if you already know the semantic environment of this sentence, such as the cold winter months or the hot summer, then it will be easy to understand the meaning of this sentence.

So a language is inseparable from its semantic environment.

The general language of business has its business boundaries, and it is unlikely that we can use a simple term to describe a complex business domain without ambiguity. The bounded context is used to subdivide the domain, thereby defining the boundary of the common language.

Let us now use an example from the insurance domain to illustrate the term boundaries. In the field of insurance business, there are insurance terms such as insurance application form, policy, endorsement, and claim, which are respectively applied to different business processes of insurance.

1. When a customer applies for insurance, the business personnel record the insurance information, and the system corresponds to the entity object of the insurance application.
2. After the payment is completed, the business personnel convert the insurance application form into an insurance policy, and the system corresponds to the policy entity object, and the insurance policy entity is associated with the insurance application form entity.
3. If the customer needs to modify the policy information, the policy becomes an endorsement, the system corresponds to the endorsement entity object, and the endorsement entity is associated with the policy entity.
4. If the customer makes a claim and generates a claim case, the system corresponds to a report entity object, which is associated with the policy or endorsement entity.

Insurance policy, insurance policy, endorsement, compensation, etc., although these terms are all related to insurance policies, the term insurance policy cannot be used in the entire insurance business field. Because terminology has its boundaries, there will be problems in understanding beyond the boundaries.

It doesn’t matter if you don’t know much about the insurance industry I work in. Surely you are familiar with e-commerce, right?

Just like commodities in the field of e-commerce, commodities have different terms at different stages. They are commodities in the sales stage and become goods in the transportation stage. The same thing, due to different business domains, gives these terms different meanings and responsibility boundaries, and this boundary may become the boundary of future microservice design.

Seeing this, I think you should be very clear that the domain boundary is defined by the bounded context .

The relationship between bounded context and microservices

Next, we further extend this concept. Take a look at the specific relationship between bounded contexts and microservices.

I assume you have bought car insurance, or heard of it. The process of auto insurance underwriting includes several main processes such as insurance application, payment, and bill issuance. If there is an accident, there will be a claim settlement process such as reporting, investigation, loss determination, and adjustment.

The insurance field is still very complicated. Here I use a simplified insurance model to illustrate the relationship between the lower bound context and microservices. We will also use some of the basics we learned in the previous article, such as domains and subdomains.

First, domains can be split into sub-domains. A domain is equivalent to a problem domain, and the process of splitting a domain into subdomains is the process of splitting a large problem into small problems. In this figure, the insurance domain is split into four sub-domains: insurance application, payment, policy management, and claim settlement.

The sub-domain can be further split into sub-sub-domains as needed, for example, the payment sub-domain can continue to be split into collection and payment sub-sub-domains. After dismantling to a certain extent, the domain boundary of some sub-subdomains may become the boundary of the bounded context.

A sub-domain may contain multiple bounded contexts. For example, the claims sub-domain includes multiple bounded contexts such as report, investigation, and damage assessment (the bounded context coincides with the boundary of the claim sub-domain). It is also possible that the boundaries of the subdomain itself are bounded context boundaries, such as the insured subdomain.

Each domain model has its corresponding bounded context, and the team communicates in a common language within the bounded context. The domain model of all bounded contexts in the domain constitutes the domain model of the entire domain.

The theoretical upper bound context is the boundary of the microservice. We map the domain model in the bounded context to microservices, and we complete the solution from the problem domain to the software.

It can be said that bounded context is the main basis for microservice design and splitting. In the domain model, if other external factors such as technical heterogeneity and team communication are not considered, a bounded context can theoretically be designed as a microservice.

However, here is a reminder: In addition to theory, there are still many limiting factors in the splitting of microservices, and excessive splitting should not be done in the design. So how to grasp this degree? I will explain in detail in the following articles about microservice design and specific splitting methods.

Summarize

The common language determines the unified language for the internal communication of the project team, and the semantic environment of this language is defined by the bounded context to ensure the uniqueness of semantics.

The main job of domain experts, architects, and developers is to divide bounded contexts through event storms. The bounded context determines the direction of microservice design and splitting, and is the main basis for microservice design and splitting. If technical heterogeneity, team communication and other external factors are not considered, a bounded context can theoretically be designed as a microservice.

It can be said that bounded context is of great significance in microservice design. If the direction of bounded context deviates, the design result of microservice can be imagined. Therefore, only when we understand the true meaning of bounded context and its role in microservice design, can we truly exert the value of DDD, which is the foundation and premise.