0 Article Overview
Domain-driven design (DDD) has been a popular concept for some time. When I first came into contact with it, I felt that there were many concepts and it was difficult to implement.
1 six questions
1.1 Why use
The core of the DDD methodology is to continuously decompose problems, decompose big problems into small problems, and break down big business into small areas. In short, it is to divide and conquer and defeat them one by one.
Divide and conquer means that we have no way to start with large business directly, so we need to decompose it according to a certain method and decompose it into highly cohesive small areas so that the business has clear boundaries, and these small areas are what we are capable of handling. This is domain-driven design. Core.
Breaking down each problem means that when the problem is divided into small areas, because the business in small areas is cohesive and its sub-fields are highly related, we can design them in detail in the technical dimension, and divide the projects according to the field in the management dimension. It should be pointed out that DDD cannot replace detailed design, DDD is for clearer detailed design.
In the Internet industry where microservices are popular, when the business becomes increasingly complex, technicians need to solve the problem of how to divide the boundaries of microservices. DDD's feature of clarifying business boundaries can be used to solve this problem.
1.2 Methods and objectives
Our goal is to divide the business into clear boundaries, and DDD is one of the effective methods to achieve the goal. This requires special attention. DDD is a method, not a goal, and does not need to be used for the sake of use. For example, businesses whose business models are relatively simple and can be easily analyzed do not need to use DDD. There are also some projects whose goal is to quickly verify the project, which is short and fast, and may not need to use domain-driven design in the early stage.
1.3 Whole and part
A domain can be divided into multiple sub-domains, and a sub-domain can be further divided into multiple sub-sub-domains. Bounded context is essentially a kind of sub-sub-domain. So when decomposing a business, is a business module a domain, a sub-domain or a sub-sub-domain?
I don't think we need to dwell on this issue, because it depends on the perspective from which this module is viewed. The whole you think may be someone else's part, and the part you think may be someone else's whole. It doesn't matter what the name is. The most important thing is to bring together highly business-related modules according to the principle of high cohesion.
1.4 Coarse and fine particle size
There is no unified standard for the granularity of business division. It must be comprehensively considered based on business needs, development resources, technical strength and other factors. For example, if microservices are split too finely, it will increase the complexity of development, deployment, and maintenance, but if the split is too coarse, it may lead to a large number of businesses being highly coupled. Development and deployment are very fast, but maintainability and scalability are lacking. A trade-off needs to be made based on actual circumstances.
1.5 Domain and data
An important difference between domain objects and data objects is the way value objects are stored. Before discussing domain objects and data objects, we first discuss the concept of entities and value objects. An entity is an object with a unique identifier, and the unique identifier will accompany the entity object throughout its life cycle and cannot be changed. A value object is essentially a collection of attributes and does not have a unique identifier.
While domain objects contain value objects, they also retain the business meaning of the value objects, while data objects can use a looser structure to save value objects, simplifying database design.
Now suppose we need to manage football player information, how should the corresponding domain model and data model be designed? Name, height, and weight are the essential attributes of an athlete, and coupled with a unique number, they can correspond to entity objects. Running distance, passing success rate, and number of goals scored are the performance of athletes in the game. The collection of these attributes can correspond to value objects.
Value objects can be stored in loose data structures in data objects, while value objects need to retain their business meaning in domain objects, as shown in the following figure:
We write domain object and data object code according to the diagram:
| //数据对象 publicclassFootballPlayerDO{ privateLongid; privateStringname; privateIntegerheight; privateIntegerweight; privateStringgamePerformance; }//领域对象 publicclassFootballPlayerDMO{ privateLongid; privateStringname; privateIntegerheight; privateIntegerweight; privateGamePerformanceVOgamePerformanceVO; } publicclassGamePerformanceVO{ privateDoublerunDistance; privateDoublepassSuccess; privateIntegerscoreNum; } |
1.6 Abstraction and flexibility
The core of abstraction is to find similarities and extract common factors for different things. The core of implementation is to find differences and expand their respective attributes and characteristics, which reflects flexibility. For example, the template method design pattern uses abstraction to build the framework and implementation to extend the details.
Let's go back to the discussion of the data model and we can find that scripting is a way to expand flexibility. Scripting not only refers to using groovy and QLExpress scripts to enhance system flexibility, but also includes loosely extensible data structures. The data model abstracts basic attributes such as name, height, and weight. For frequently changing game performance attributes, these attribute values may change frequently, and even the attributes themselves may change frequently. For example, the number of shots, the number of breakthroughs, etc. may be added, so it is adopted Stored in a loose JSON data structure.
2 six steps
Engineering theory always needs to be implemented, and implementation also requires some steps and methods. In this article, we analyze a football player information management system. The goal is to manage the entire link information of athletes from transfer to playing games. You may have never been exposed to this system, so let's analyze it together. It should be noted that this example focuses on demonstrating how to implement the DDD methodology, and the business details may not be comprehensive.
2.1 Process overview
There are two issues that need to be considered during the sorting process. The first question is from what perspective should we sort out? Because different people see the process differently. The answer is that it depends on what problem the system needs to solve, because we need to manage the entire link information of athletes from transfer to playing games, so starting from the athlete's perspective is a suitable choice.
The second question is what should I do if I am not familiar with the business? Because we are not sports and exercise experts, we do not know the business details of the entire link. The answer is that business experts must be present when sorting out the process, because without real business details, domain-driven design is impossible. Similarly, when sorting out complex business processes on the Internet, product managers or operations who are familiar with the relevant business must participate.
Assume that football business experts have sorted out the business process, the athlete proposes a transfer, and after consensus is reached, he goes to the new club for a physical examination. If the physical examination is passed, the contract will be signed. After entering the new club, train, play the game after meeting the training indicators, and attend the press conference after the game.
2.2 Four-color modeling
(1) Time stamp object
The first color in four-color modeling is red, which represents the time scale object. The time stamp object is the most important object in four-color modeling and can be understood as a core business document. During the business process, documents must be left for key businesses. Through these documents, the entire business process can be traced.
The time scale object has two characteristics: first, it is the immutability of facts, which records the facts that occurred at a certain time point or time period in the past. The second is responsibility traceability, which records the information that managers are concerned about. Now we analyze what time stamp objects are included in this system and what core business documents need to be left behind.
Transfers correspond to transfer documents, physical examinations correspond to physical examination documents, signed contracts correspond to contract documents, training corresponds to training indicator documents, matches correspond to match indicator documents, and press conferences correspond to interview documents. Draw the following time scale objects based on the analysis:
(2) Participants, places and things
These three types of objects are represented by green in four-color modeling. We take the e-commerce scene as an example to illustrate. When a user pays to purchase a merchant's goods, the user and the merchant are participants. When the logistics system delivers goods, the delivery document needs to have a delivery address object, and the address object is the place. Orders require product objects, logistics and distribution require goods, and goods and goods are objects.
When we analyze this example, we can see that the participants include general managers, team doctors, coaches, fans, and reporters, the locations include training locations, game locations, and interview locations, and the objects include signed jerseys and signed footballs:
(3) Role object
In four-color modeling, represented by yellow, this type of object indicates the role of participants, places, and objects in the business process:
(4) Description object
We can add relevant description information to the object, which is represented by blue in four-color modeling:
2.3 Divide areas
During the four-color modeling process, we realized that the time stamp object is the most important object because it carries the core documents of the business system. When dividing the domain, we are also inseparable from the time scale object, and divide the domain by converging related time scale objects.
2.4 Domain events
When something happens in the business system, if there are follow-up actions in this field or other fields, then we call this thing a domain event, and this event needs to be perceived.
For example, if a player is injured during a game, this is a game subdomain event, but the medical and training subdomains need to be aware of it. Then the game subdomain will send out an event, and the medical and training subdomains will subscribe.
For example, if a player scores a goal in a match, this is also a match subdomain event, but the training and contract subdomains will also pay attention to this event, so the match subdomain will also send out a match goal event, and the training and contract subdomains will subscribe.
There is a problem that needs to be noted through event interaction. Implementing business through event subscription can only adopt final consistency and needs to give up strong consistency. This may introduce new complexity and require trade-offs.
2.5 Project construction
(1) api
Interface layer: Provides external interface declarations and DTO objects
(2) controller
Access layer: Provides HTTP access entrance
(3) service
Business layer: Both the domain layer and the business layer contain businesses, but have different purposes. The business layer can combine businesses in different fields, and can add flow control, monitoring, logging, and permission control aspects. It is richer than the field layer and provides BO objects.
(4) domain
Domain layer: Provides DMO (DomainObject), VO, events, and data access objects. The core is subcontracting according to the domain. High cohesion within the domain and low coupling between domains.
(5) dependency
External access layer: In this module, external RPC services are called and return codes and data are parsed.
(6) infrastructure
Basic layer: includes basic functions, such as caching tools, message queues, distributed locks, message sending, etc.
We expand the domain layer for analysis. The core of the domain layer is to subcontract according to the domain and provide DMO, VO, events, and data access objects. It has high cohesion within the domain and low coupling between domains. For example, domain1 corresponds to the contract subdomain, domain2 corresponds to the training subdomain, and domain3 corresponds to the contract. Subdomains.
2.6 Detailed design
So far, the field has been determined. Now the tasks can be divided according to the field. Members of the group are responsible for detailed design in one or more fields. This stage is the use case diagram, activity diagram, sequence diagram, database design, and interface design that everyone is very familiar with. of use. It should be noted that domain-driven design does not replace detailed design, but to provide clearer detailed design.
3 Article summary
This article discusses six issues that need to be paid attention to when implementing DDD, and implements the six steps through a football player information management system case. In practical applications, each business form is very different, but the methodology can be universal. We need to make it clear that the core of DDD is to divide and conquer, and use some proven and effective methods for modeling. I hope this article will be helpful to everyone.