Do you really understand the domain model?

UML is difficult to learn, mainly because it is complicated and involves a large number of conceptual nouns. Domain model is one of them. There should be two kinds of knowledge about domain model found on the Internet, one is from the initial traditional software development process, and the other is from domain-driven design (DDD), which is easy to be confused. The following is my understanding of the concept of domain model.

Theoretical school

Domain model is a special business model, which analyzes the whole industry and abstracts the businesses with * * * and internal regularity in the industry, which is more abstract than business model. Does not belong to the concept of software development, and has nothing to do with software development.

Actual combat school

Domain model is an analysis model, which is used to analyze how to meet the functional requirements of the system in the analysis stage of software development process. It belongs to the category of software development, and class diagram is mainly used to describe the domain model in UML.

Business model is the output of business modeling. The research object of business modeling is a company or an organization, and business modeling belongs to the primary stage of software development.

Software development process: business modeling, requirements, analysis and design.

In the process of software development, the domain model we come into contact with belongs to the actual combat school.

Theoretical school

Domain model is a special business model, and its functions are:

Actual combat school

Role of domain model:

The role of business model:

Theoretical school

Domain model is a special business model, so it has all the characteristics of business model, but it is more abstract and universal than business model.

Actual combat school

In the process of software development, the business model is generated in the business modeling stage and the domain model is generated in the analysis stage.

The business model is the product that the system requirements personnel understand the business of the customer company, and the requirements in the next stage will be input by the business model to get the system requirements.

Domain model is the product of system analyst's analysis on how to meet the functional requirements of the system. The next stage of the design will take the domain model as input.

The "actual combat faction" gave an example:

When receiving a project, we need to set up a hotel reservation system. First of all, it is necessary to establish a business model to understand the related business of hotel management of the client company, which will produce a business model. At this time, the business model includes other business links at the same level as hotel reservation besides the business links of hotel reservation.

Next, focus on hotel reservation, improve the existing process to get the requirements of hotel reservation system, that is, system use cases and requirements specifications.

Next, by analyzing the system use cases and requirements specifications, how to meet the functional requirements of the hotel management system is analyzed, so as to get the domain model.

The domain models of "theoretical school" and "practical school" belong to two categories, and if they are not clearly distinguished, it will definitely lead to confusion in understanding.

There is also a "domain model", which is called "domain-driven design" by Eric Evans for short. DDD is an object-oriented modeling method, which is used for comprehensive software system analysis and design, so it is necessary to clearly distinguish these two domain models. Concepts such as blood loss model, anemia model and congestion model all belong to the domain model of DDD.

1. The core problem is different.

As mentioned above, the domain model is an analysis model used to analyze business, and the core problems that need to be solved in actual projects are:

The "domain model" is a comprehensive analysis and design model, and the core problems to be solved are:

In the traditional software development process, analysis (system requirements analysis) and design (system design) are divided into two stages, corresponding to the titles of "system analyst" and "system designer" respectively. As a result of this separation, the "system designer" can only code after making the system design according to the results of requirements analysis, and information will be lost or distorted in the middle, and business requirements will change in the actual process (possibly due to external environment). The DDD idea put forward by Eric Evans is to solve this problem.

2. Different fields

The domain model is a business analysis model, which analyzes the business of the core domain according to the functional requirements of the system. Software system is only a way to realize business, not a part of business (except for companies providing IaaS services), and will not consider the IT field of system design.

"Domain model" is a comprehensive analysis and design model, which involves system design and needs to consider the boundary of the system, so the domain of this model analysis and design is a comprehensive business domain and IT domain.

Taking the hotel reservation system as an example, its business description is as follows.

There are two objects involved: users and members.

If you do business analysis, the "users" in the first paragraph may need to be considered, which may be the business meaning of tourists and consultants.

If you want to consider the system design, the "user" in the first paragraph may be ignored, that is, it is not within the system boundary.

3. Different stages and positions of use.

Domain model is an analysis model for analyzing business, which is mainly used by system analysts in the analysis stage of actual projects.

DDD's "domain model" is a comprehensive analysis and design model, which spans two stages of analysis and design in practical projects. The position needs to have the comprehensive ability of "system analyst" and "system designer".

4. The content is different

Main contents of domain model:

Main contents of "domain model":

Domain model is divided into theoretical school and practical school. Theoretical school belongs to the business category, not to the software development category. In the process of software development, theoretical schools should be ignored to avoid mutual confusion.

The practical school thinks that domain model is an analytical model, which is used to analyze and understand complex business domain problems. Specifically, in the process of software development, it is to analyze how to meet the functional requirements of the system in the analysis stage.

At the same time, in the field of software development, there is also a "domain model" from DDD, which integrates comprehensive analysis and design, pays attention to the connection between system design and requirements analysis, and the designed system has good consistency with requirements and is more scalable to reasonable requirements changes.