Why should you care about the domain model?

Introduction to domain model is the core of DDD, and it is the in-depth knowledge of the business

author of Zhang Gang, PhD in software engineering, senior technical expert of Alibaba Cloud Cloud, and core member of ALPD methodology.

reader benefits : Go to:

https://developer.aliyun.com/topic/course/alpd

Receive free Ali’s popular architect course "DDD Master Advanced 12 Lectures" (original price 98 yuan).

introduction

The domain model is an important concept. However, not many people really understand and can use it proficiently. This is really a pity.

Many problems in software development, such as difficult communication of requirements and difficult evolution of software, are closely related to domain models. More importantly, it is not difficult to master this concept. Through practice, a team only needs one or two hours to get used to the modeling ideas of the domain model and begin to benefit from it.

So, what is a domain model? How to understand the nature of the domain model? Why can domain models be of great help to software development? How to express it, how to apply it? This article will expand these concepts in turn.

What is a domain model?

First, let's look at what is a domain model.

The domain model defines the key concepts in the domain and the relationships between these concepts.

​

Why should we emphasize "in the field"? It is because the model (or concept) only makes sense in the problem space in which it is located. This is divided into two situations:

1) A concept is meaningful only in a specific field. For example, "accounts receivable" only makes sense in the financial field, and more strictly in the accounting field.

2) A concept must be restricted by the domain to have specific meaning. For example, the concept of "track" may be the track of planetary motion in the field of astronomy, or it may be the track of train in the field of railways. The field must be limited first before this concept has real value.

Key Message 1: The most important thing about the domain model is the concept, and the domain model is also called the conceptual model.

Although some people say that "a domain model is a visual representation of concepts in the domain", "visualization" is not essential, although it is also important. In comparison, the "concept" is the fundamental.

key message 2: "The boundary of language is the boundary of thought"-a good domain model must carry useful knowledge.

For a person who is not familiar with a particular field, understanding concepts is often the fastest way to enter a field. For example, a nursery rhyme in childhood: the sun is big, the earth is small, and the earth runs around the sun. The earth is big, the moon is small, and the moon runs around the earth. It can be considered as an expression of a conceptual model. In this model, three conceptual entities are included: the sun, the earth and the moon. The relationship between the sun and the earth is that the earth moves around the sun, and the relationship between the earth and the moon is that the moon moves around the earth. With a picture, it is:

This picture is actually an object diagram of UML. Of course, even if you are not familiar with UML, it can be easily understood as a wireframe.

Similarly, in various business areas, they have their own key concepts. The expression of these concepts is not necessarily a graph. For example, in the accounting field just mentioned, we can use a table to express the following key concepts:

<span>Accounting entity (own party) -> the other party</span>
<span>account receivable has not been sent to the other party but	payment </ span>
<span> accounts payable </ span>	<span> has received other goods, but not yet paid the purchase price </ span>
<span> prepaid accounts </ span>	<span>The payment has been received, but has not yet been shipped</span>
<span>Prepaid accounts</span>	has not been paid for the goods <span> </span>

Through such a form, I believe that even if you don't know much about the accounting field, you can quickly grasp the relevant knowledge. If we go further, we can understand that receivables and prepayments are essentially our party’s claims, while prepayments and payments are essentially our own debts. A picture is: Here we use UML class diagram to represent. For those who are not familiar with UML, you may need to explain the meaning of the triangle arrow, which stands for "a kind of", for example, accounts receivable is a kind of debt. More stringently, if an account receivable has a very long period, such as 5 years, then there is a high probability that this type of account will not be collected, so bad debts need to be accrued. There are some general bad debt accrual strategies, such as: 5% within one year, 20% within one to two years, 50% within two to three years, and 100% over three years. Therefore, for the accounts receivable just now, we can use the following diagram to express this concept: The graph is a view, it does not need to be comprehensive. For example, this figure does not show all the information related to accounting subjects, but only focuses on the provision of bad debts. Among them, we have introduced a new symbol between accounts payable and bad debts. Friends who know UML know that we are expressing "Accounts receivable includes bad debts". The account period, amount, etc. in the figure, we become "attributes", which are used to explain in detail what the concepts of accounts receivable and bad debts include. ​ Since the domain model essentially conveys concepts and knowledge information, for software development scenarios, making this knowledge explicit can quickly align the concepts between different roles and different participants, and accelerate communication. Avoid misunderstandings. ​ # Domain model is an important business asset ## The domain concept accumulates business knowledge and is very stable. What is the difference between a company that has been in a certain field for many years and a new company? The gap may be multifaceted, but the biggest gap should be "cognition." ——So we often see that the way for new entrants to catch up with companies that have been cultivating for many years is often to "dig corners" with high salaries in mature companies. It stands to reason that these dug-out people can neither bring the original company’s customers nor the original company’s systems, so what do they essentially bring to the new enterprise? Their greatest help to the new company is their knowledge of specific areas. In the business area, cognition is very valuable and very stable. We will also see that some companies that have established advantages in a certain field, especially consulting companies, can bring objective income to the company by relying solely on consulting in the business field. If there is a well-maintained domain model, then the domain model is the best location for these cognitive precipitation. More importantly, although the business is often new, the domain model is quite stable. Let's take commodity trading as an example. We know that the concepts of buyers, buyers, commodities, and transactions are all core concepts in the field of commodity trading. These concepts will not change drastically with the evolution of business, whether it is B2C business, C2C business, C2M business, group business or spike business. Different businesses only reflect different ways of organizing these business concepts. Of course, the real domain model is much more complicated than the above concepts. Here we just give a simple example to illustrate the stability of the domain concept. ## The transition and growth of the domain model Of course, when we say that the domain model is stable, we don't mean that it stays the same. Excellent domain models are bound to continue to grow, and sometimes even undergo essential transitions. Once a model is overthrown, we will think that our understanding of a certain field must have undergone a very essential transition. For example, the aforementioned nursery rhyme "The sun is big, the earth is small, and the earth runs around the sun. The earth is big, the moon is small, and the moon runs around the earth." This is not how it was understood from the beginning. Both at home and abroad, hundreds of years ago, we thought that the earth is the center of the universe, and that the sun and the moon revolve around the earth. Then, this model is drawn as follows: Geocentric object map When it comes to heliocentric theory, it is our universe that has made great progress, thinking that the heliocentric model completely negates the geocentric model. The same is true in the software field. I have experienced several domain model transition scenarios, and each time it has been accompanied by a huge improvement in business cognition. Of course, in real life, transitions are rare. More often, they are developing steadily on the original model, gradually adding various new concepts and various details. The growth process of the model is essentially the process of accumulating business capabilities. ## Stable domain model brings software adaptability The demand is unstable, and the domain model is stable. This enlightens us that if we build software with the domain model as the center, then we will construct a lot of stable building blocks. New demands can form a variety of applications through these stable building blocks and different construction methods. In this case, our software has the strongest adaptability to changes and the lowest development cost. # Where does the domain model exist ## Use class diagrams to represent domain models UML class diagram is a very good tool for expressing the domain model, although there is no standard for how to express the domain model. Because in UML, "class" is not simply a "class" in software design, it actually represents a "concept", so it is very appropriate to use class diagrams in the expression of domain models. Moreover, UML has agreed on the concept and the relationship between concepts, such as: class, attribute, association, multiplicity of association, generalization, aggregation, composition, dependency, etc. For those who are not familiar with UML, there is no need to have any psychological burden to use UML. UML is a highly flexible structure with asymptotic capabilities. You don’t need to master all the complicated concepts before you start working. According to my experience, as long as you can describe the class (representative concept), the properties of the class and their relationship at the beginning, and at most know how to express the multiplicity, it is enough to deal with the big problem. Most scenes. Some friends have object-oriented experience, and here will be entangled in whether to model the "method/operation". In the context that the "domain model" is a "business concept", the method is completely redundant, and there is no need for modeling at this stage for the time being. I think it is more appropriate to make up for them at the realization stage. ## Use domain models in communication and documentation Writing the domain model on paper is not the most critical. As a conceptual model, it reflects the most important concepts in this field and also constitutes a vocabulary for expressing business concepts. and so: best domain model of 160cc2e143d30d should always exist in the hearts of team members and in daily communication activities. ​ In order to achieve this, I have a requirement for my team and the team I have coached. This requirement has also become the "unified language" in communication activities: Any concept that appears in the requirement description must appear in the domain model. If there is a relationship between concepts in the requirement description, this relationship must also be present in the domain model This requirement may seem simple, but it will be more difficult to actually achieve it. Especially at the beginning, team members may not be used to this practice, often forget this guideline, and need to be corrected frequently. But once you get used to it, everyone will find that in daily communication activities, because all concepts have been made explicit, misunderstandings are greatly reduced, and consensus is easier to reach. The result is that the final team members will very consciously maintain the "unified language" way of doing. For the same reason, using the domain model as a unified language when writing documents has also become a very natural result. ## Use the domain model in the code Since the domain model has been made explicit, if the domain model can be used in the code, the code will get better legibility. Since the domain model and the code correspond to more consistent, then when the domain model evolves, the code will become easier to evolve. In this regard, domain-driven design provides a complete set of patterns that can help architects and developers to naturally transform domain models into code. We are not going to expand these patterns in this article. Here, for the time being, readers are asked to remember the following conclusions, and there will be more in-depth discussions later: code and the problem domain should be minimized. The domain model is the best bridge between the real world and the digital world. Using the domain model as the basic expression element of the business concept in the code can greatly improve the legibility of the code and better support the evolution of the business. # Where does the domain model come from The domain model reflects key business perceptions, but perceptions are not built out of thin air. To be able to understand the essence of everything as soon as it comes up, either this person is a genius, or it means that this field is already a very mature field, and there is no need for exploration and discovery. Most of the time, cognition is inspired by business scenarios. Therefore, the process of domain model establishment is often accompanied by requirements analysis. I drew the following picture to illustrate the relationship between the domain model and business scenarios: In other words, the domain model is gradually improved under the incentive of business scenarios. Moreover, in turn, because of the deeper understanding of the domain, the domain model also helps the discovery of new business scenarios. It is best not to explore and discover alone. More often, collective modeling should be done as much as possible. Collective modeling is not only conducive to exploration and discovery, but it also helps to reach a consensus on key business concepts. The best tool for collective modeling is not the electronic tool of UML. Using whiteboards and discussions in open spaces can often achieve the best results. Since the domain model expresses the concept, it is the basic skill of domain modeling to decompose and abstract the concept in time. Of course, there are not many people who have received strict decomposition and abstract training in reality, especially many business personnel often lack this ability. In my actual work, I have observed that developers with object-oriented experience can quickly master this skill after a certain period of practice. Therefore, if there are some experienced developers involved in modeling, a higher quality model can often be obtained. # Common Misunderstandings The concept of domain model originated in the object-oriented community in the 1990s. At that time, business changes were not as frequent as they are today, the idea of ​​iteration has not yet fully matured, and business personnel and technical personnel did not communicate as intensively as they are today. Therefore, whether it is from reference books or in practice, the field The concept of the model inevitably leaves the influence of the early practices. Among them, there are several misunderstandings, which should be avoided as much as possible in practice: ## Misunderstanding 1: Modeling the domain model from a development perspective A technician often asks: "What is the relationship between the domain model and the ER diagram?" The most direct answer to this question is: "It doesn't matter." Of course, I definitely know that after having a domain model, it will be easier to design ER diagrams, or for a legacy system that lacks a domain model, studying the database structure can bring effective input, but their footings are completely different. . The domain model must be viewed from a business perspective, because the domain model reflects business cognition. Once the concept of technology is mixed into the domain model, it is not only because it is not pure enough, but more importantly, it has blocked the opportunity to evolve and correct the domain model from a business perspective. Because it is impossible for a business person without a software background to look at a model full of technical concepts. If a unified language cannot be established, a large part of the value brought by the domain model has been lost. In addition, modeling from a development perspective often overlooks the participation of business personnel. Practice has repeatedly shown that experienced business personnel can often provide in-depth insights when modeling domains. Therefore, modeling the domain model from a development perspective is absolutely not advisable. ## Misunderstanding 2: Building a huge domain model When we say "domain", we don't limit how big a "domain" should be. Is "aviation" as a field, or is "ticket booking" in "aviation" a field? When you consider that "the core of the field is cognition", the answer becomes very clear. The larger the field, the less conducive to building awareness and consensus. We should divide the big domain into small domains in this problem domain, and then build domain models of these small domains one by one. The domain model of a whole wall is often undesirable. ## Misunderstanding 3: Focus on documentation, not communication and consensus The core of the domain model is to establish a common consensus. Therefore, it is very inappropriate to treat the domain model as a "product" and the "output" of a certain stage. The domain model needs to be used as a communication tool. "Unified language" is an important way to avoid this misunderstanding. ## Misunderstanding 4: Do not make the domain model explicit Many people think that they have "cognition" or even a "domain model". However, if you ask them where the model is, it is either that there have been some discussions in a certain project, but they are nowhere to be found. , Or although the documentation is still there, the concept of the team is still confused. Without being explicit, without writing down the domain model, and without forming the team’s word-of-mouth knowledge, then this model does not really exist. In addition to the "unified language", we also have a very simple way to check, which is to see how the team introduces their system to newcomers. Because the domain model reflects the basic business concepts and is a very good tool for newcomer training, it is impossible for organizations that truly have a "domain model" to introduce the domain model. # to sum up In this article, we mainly introduce the basic concepts and importance of the domain model, the value of the domain model to the "unified language", and the common misunderstandings in the application of the domain model. To summarize the main points: * The essence of the domain model is concept and cognition, it defines the key concepts in the domain and the relationship between these concepts * Compared with the volatile business, the domain model is relatively stable. A high-quality domain model can support the business at low cost. The domain model is also the basis of a unified language, which can effectively improve communication efficiency. * The domain model comes from the process of business nourishment, domain model growth, and the process of building business cognition. Collaborative modeling is a more effective modeling method Do you have an explicit domain model and common business knowledge in your team? Is it guiding daily communication and development work? If not, let's get started. * Course recommendation: "12 Lectures on Advanced DDD Masters" The content of this article is derived from the "ALPD Cloud Architect Series-12 Lectures on Advanced DDD Masters" launched by Alibaba Cloud. This is a popular course within Alibaba. It has been recommended by thousands of Alibaba engineers and is worthy of repeated learning by every developer. Or go to the following link on the PC to get the course, and get the free Alibaba Explosive Architect Course "12 Lectures on Advanced DDD Master" (original price: 98 yuan) https://developer.aliyun.com/topic/course/alpd > Copyright Statement: content of this article is contributed spontaneously by Alibaba Cloud real-name registered users. The copyright belongs to the original author. The Alibaba Cloud Developer Community does not own its copyright and does not assume corresponding legal responsibilities. For specific rules, please refer to the "Alibaba Cloud Developer Community User Service Agreement" and the "Alibaba Cloud Developer Community Intellectual Property Protection Guidelines". If you find suspected plagiarism in this community, fill in the infringement complaint form to report it. Once verified, the community will immediately delete the suspected infringing content.