Conclusion first:
In DDD, a generic language is bounded by a bounded context. If a product or project has multiple bounded contexts, we need to define a common language for each bounded context. A bounded context provides a semantic boundary to maintain a one-to-one correspondence between common language and domain concepts. This constraint solves the ambiguity caused by the same noun corresponding to different business concepts in different scenarios and opportunities in the real world, and helps the team communicate without ambiguity when using the common language.
First taste of “Universal language”
My first insight into how to build a common language came from the case studies in Chapter 1 of Domain-Driven Design. This example vividly demonstrates how developers can establish a common language of understanding and use it to communicate with domain experts. Based on that case, my understanding of building a common language at the time was:
- Technical people use business people’s language as a development vocabulary;
- Divide the aggregate and associate these terms with the aggregate;
- Technicians map these terms to code implementations;
- These vocabularies will expand as the project progresses;
With this understanding in mind, I put some small projects I was in charge of into practice, and the results were very good. For a long time, the team’s developers have experienced the pleasure of smiling and understanding when interacting with business people. I seldom hear the criticism, “This is not what I want.”
The “common language” becomes obscure when it comes to words of the same name
However, when I came to ThoughtWorks and worked on projects involving dozens of people, I found that a common language built around this principle couldn’t guarantee unambiguous communication within the team when it came to a polysemy word of the same name. This ambiguity can lead to team members saying the same thing and thinking about different things, for example:
- The business vocabulary of the same name is not clear with the actual business: “Why can’t we add a complaint field to the sales order, which is displayed in the sales order on the interface” — how to determine what the sales order is, what can be done and what can’t be done?
- The business words of the same name are associated with different business words: “I changed the buyer’s information after the payment of the sales order, why do I see the buyer changed in the reservation of the sales order” — how many buyer’s information are there?
- The relationship between the business words of the same name is not clear: “Why do I change the buyer’s address on the profile and the buyer’s address on the sales order?”
Remove ambiguity by adding constraints
The following figure is a metamodel diagram of DDD concepts. From the lower left corner of the figure, we can see that there are two additional constraints when building a generic language: subdomains and bounded contexts.
In DDD, the core of software is its ability to solve domain-specific problems for customers
The domain here refers to the collection of things related to the actual problem that the software system is trying to solve.
For example, to develop an e-commerce system for an e-commerce company, we need to understand the profit model of the e-commerce company based on the operation mode and business rules of the profit model, such as how to purchase goods, how to promote sales, how to logistics and so on. All things related to the business belong to the field.
The domain is divided into problem domain and solution domain.
In order to decompose the complexity of the problem domain, the problem domain is divided into multiple subdomains, each of which defines the business problem and process to be solved, as well as the business value brought to the enterprise by solving the business problem (this is the cause, the business process and the business problem to be solved is the effect).
After defining the subdomain clearly, we can build a common language to extract the domain knowledge of the subdomain, and build a domain model for solving problems based on the common language.
A domain model exists in a bounded context. A bounding context is used in DDD to define the scope of the model, its purpose, and where it should be consistent, and it allows the team to clarify what the responsibility boundaries of the model are. At the same time, the universal language is restricted to the bounded context; A bounded context provides a semantic boundary in which each term of the common language must correspond to a domain concept.
Ideally, there is a one-to-one correspondence between subfields and bounded contexts. However, the granularity of subdomain division, current status of legacy systems, language ambiguity, team structure and other subdomains may correspond to 1: N or N: N bounded contexts.
Through mapping between bounded contexts, multiple models in the context collaborate to meet system requirements. We can also learn whether and what kind of relationships exist in the same words in different contexts.
For common languages, subdomains explain the relationship between common languages and real-world business activities. The bounded context provides a semantic boundary to maintain the one-to-one correspondence between common language and domain concepts. Context maps provide conversion relationships for common languages above and below different boundaries.
To solve the previous problem
There are ambiguities in the order and related concepts mentioned above. Let’s look at how these ambiguities can be resolved through subdomains, bounded contexts, and context maps:
Confusion caused by the unclear relationship between the business vocabulary of the same name and the actual business
“Why can’t we add a field of complaint or not in the sales order, which is displayed on the sales order in the interface?”
Assuming that the sales order exists in the sales subdomain, the order should solve a problem in the sales process. The life cycle of an order begins with a sale and ends with a sale. Generally speaking, the complaint belongs to the after-sale link, and the declaration of the complaint field in the sales order means that the function of the sales order has broken through the sales subdomain. Sales orders on the UI display aggregated information that is not necessarily consistent with the domain model of the same name.
Confusion caused by the association of a business word of the same name with a different business word
“I changed the buyer’s information after the payment of the order. Why did I see that the buyer in the reservation of the order also changed?”
There are two types of buyer information on the order, and you can distinguish two terms with the same meaning but different terms by isolating them in different contexts. Two contexts are established in the sales subdomain, namely, the reservation bounded context and the purchase context, and the order domain model is split into these two contexts. In different contexts, the order has its own buyer information, which solves the problem of “after the order payment changes the buyer information, why do I see the order reservation has also changed the buyer”.
Confusion caused by unclear relationships between business words of the same name
“Why if I change the buyer’s address on my profile, the buyer’s address on my order will change?”
The order exists in the purchase context, the profile exists in the context of identity information, the purchase context and the identity information context there is a mapping relationship, when the order is created from the identity information context copy the buyer’s address, stored separately in the order. This solves the problem of “why does the buyer’s address on the order change when I change the buyer’s address on my profile?”
Reference:
- Domain-driven Design
- Implementing Domain-Driven Design
- When subdomains meet a Bounded Context
- DDD’s ultimate trick – By Experience
- Domain-driven Design Learning: Domain, Subdomain, and Bounded Context
The text/ThoughtWorks wang attended
For more insights, please follow our wechat account ThoughtWorks Insights