Welcome to pay attention to the public account “JAVA Front” to view more wonderful sharing articles, mainly including source code analysis, practical application, architecture thinking, workplace sharing, product thinking and so on, at the same time, welcome to add my wechat “JAVA_front” to communicate and learn together

0 Article Overview

Domain-driven design (DDD) has been a popular concept for some time, but it is difficult to implement many concepts when using it. This paper will discuss the DDD landing need to pay attention to six problems, and through a football player information management system case analysis landing six steps.

1 Six questions

1.1 Why is it Used?

The core of DDD methodology is the continuous decomposition of problems, the decomposition of big problems into small problems, the decomposition of big business into small areas, in short, is to divide and conquer, one by one.

Divide and conquer means that we have no way to start a large business directly, and we need to decompose it into small areas with high cohesion according to certain methods, so that the business has a clear boundary, and these small areas are what we are capable of dealing with. This is the core of domain-driven design.

It means that when problems are divided into small areas, because the business of small areas is concentrated and their sub-areas are highly related, we can carry out detailed design in the technical dimension and divide the project according to the field in the management dimension. It is important to point out that DDD is not a substitute for detailed design, DDD is for clearer detailed design.

In the Internet industry, where microservices are popular, as businesses become more complex, technologists need to figure out how to define microservice boundaries. DDD’s clear business boundaries feature 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 most effective ways to achieve that goal, which requires special attention. DDD is a method, not a target, and does not need to be used just for the sake of use. For example, businesses with simple business models that can be easily analyzed do not need TO use DDD, and some projects with the goal of fast validation type that pursue short and fast, may not need to use domain-driven design at the beginning.

1.3 Whole and part

A domain can be divided into multiple subdomains, and a subdomain can be divided into multiple subdomains. A bounded context is also a subdomain in essence. So is a business module a domain, a subdomain or a subdomain in the process of business decomposition?

I don’t think you need to worry about that, because it depends on how you look at the module. What you think of as a whole may be someone else’s part, and what you think of as a part may be someone else’s whole. It doesn’t matter what the name is, what matters most is the convergence of modules that are highly relevant to the business 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, but it should be considered comprehensively based on business needs, development resources, technical strength and other factors. For example, if microservices are split too carefully, it will increase the complexity of development, deployment and maintenance. However, if the split is too coarse, a large number of services may be highly coupled. Development and deployment are fast, but lack of maintainability and scalability, which need to be weighed according to the actual situation.

1.5 Field and data

One important difference between domain objects and data objects is how value objects are stored. Before discussing domain objects and data objects, let’s first discuss the concepts of entities and value objects. An entity is an object with a unique identity, which is present throughout the entity object’s life cycle and cannot be changed. A value object is essentially a collection of attributes and is not uniquely identified.

Domain objects retain the business meaning of value objects while containing them, while data objects can hold value objects in a looser structure, 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 a unique number can correspond to the entity object. Distance run, pass success rate and goals scored are the performance of the player in the match, and the set of these attributes can correspond to the value object.

Value objects can be stored in loose data structures in data objects, while value objects need to retain their business meaning in domain objects:

Code domain objects and data objects according to the diagram:

// Data object
public class FootballPlayerDO {
    private Long id;
    private String name;
    private Integer height;
    private Integer weight;
    private String gamePerformance;
}

// Domain objects
public class FootballPlayerDMO {
    private Long id;
    private String name;
    private Integer height;
    private Integer weight;
    private GamePerformanceVO gamePerformanceVO;
}

public class GamePerformanceVO {
    private Double runDistance;
    private Double passSuccess;
    private Integer scoreNum;
}
Copy the code

1.6 Abstraction and flexibility

The core of abstraction is finding the same, extracting common factors from different things. The core of the implementation is to find differences and extend their respective attributes and characteristics. The template approach design pattern, for example, builds the framework with abstractions and extends the details with implementations.

Returning to the discussion of data models, scripting is a way to extend flexibility, not just with Groovy and QLExpress scripts, but with loose, extensible data structures. The data model abstracts the basic attributes such as name, height and weight. For the frequently changing performance attributes, the values of these attributes may change frequently, and even the attributes themselves may also change frequently, for example, the number of shots and breakthroughs may be added, so the loose JSON data structure is used for storage.

2 Six Steps

Engineering theory is always landing, landing also needs some steps and methods. In this paper, we analyze a football player information management system, the goal is to manage the player from the transfer to the game of the whole link information, this system we should also have no contact, we will analyze together. It should be noted that this example focuses on demonstrating how the DDD methodology works and that the business details may not be complete.

2.1 Process Combing

There are two problems to be considered in the carding process. The first problem is from what perspective? Because different people see the process differently. The answer is that it depends on what problem the system is trying to solve, because we have to manage the whole link from the player’s transfer to the game, so it’s a good choice to start from the player’s point of view.

The second question is what to do if you are not familiar with the business? Since we are not sports and exercise experts, we do not know the business details of the whole link. The answer is to have a business expert present when you comb through the process, because without real business details, you can’t domain-driven design. Similarly, when sorting out complex business processes on the Internet, product managers or operators who are familiar with relevant businesses must be involved.

Suppose a football business expert has sorted out the business process, a player proposes a transfer, gets a medical at a new club by consensus, and signs a contract once the medical passes. After entering the new club, I trained. After reaching the training quota, I played in the game and attended the press conference after the game.

2.2 Four-color modeling

(1) Time index object

The first color for four-color modeling is red, representing the time scale object. The timing object is the most important object in four-color modeling and can be understood as the core business document. In the process of business, it is necessary to leave documents for key business, through which the whole business process can be traced.

The time scale object has two characteristics: the first is the fact immutability, which records the fact that happened at a certain point or time in the past. The second is accountability traceability, which records the information that managers are concerned about. Now we analyze what the target of the system is and what core business documents need to be left.

Transfer documents correspond to transfer documents, medical documents correspond to medical documents, contract documents correspond to contract documents, training documents correspond to training indicators, matches correspond to competition indicators, press conferences correspond to interview documents. According to the analysis, draw the following timescale objects:

(2) Participants, land and objects

These three types of objects are represented in green in four-color modeling, and we take the scene of electric shopping mall as an example to illustrate. When the user pays to buy the goods of the merchant, the user and the merchant are the participants. Delivery documents of logistics system need to have delivery address object, and address object is place. Order needs goods object, logistics distribution needs goods, goods and goods are things.

By analyzing this example, “participants” include general manager, team doctor, coach, fans and journalists, “ground” includes training address, match address and interview address, and “things” includes signed jerseys and signed football balls.

(3) Role object

Represented in yellow in four-color modeling, these objects represent the roles in which participants, places, and objects participate in the business process.

(4) Description object

Add the description of the object in blue in the four-color modeling method.

2.3 Dividing domains

In the process of four-color modeling, we realize that time mark object is the most important object, because it carries the core documents of the business system. When dividing domains, we also cannot do without time scale objects, and the core is to divide business domains by convergent related time scale objects.

2.4 Domain Events

When something happens to a business system, we call it a domain event if there is follow-up action in the domain or other domains, and that event needs to be perceived.

For example, if a player gets injured during a match, this is a match subdomain event, but the health and training subdomains are aware, then the match subdomain emits an event, and the health and training subdomains 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 also pay attention to this event, then the match subdomain will also emit an event, and the training and contract subdomains will subscribe.

One thing to be aware of through event interaction is that implementing a business through event subscription only takes final consistency and requires the abandonment of strong consistency, which may introduce new complexity trade-offs.

2.5 Project Construction

(1) API

Interface layer: Provides externally oriented interface declarations and Dtos

(2) controller

Access layer: Provides HTTP access points

(3) service

Business Layer: Both the domain layer and the business layer contain the business, but for different purposes. The service layer can combine services of different domains and add flow control, monitoring, logging, and permission control facets. Compared with the domain layer, the service layer provides BO objects

(4) domain

Domain layer: provides DMO (DomainObject), VO, event and data access objects. The core is subcontracting according to the domain, with high cohesion within the domain and low coupling between the domains

(5) dependency

External access layer: In this module, the external RPC service is invoked to parse the return code and return data

(6) infrastructure

Base layer: contains basic functions such as caching tools, message queues, distributed locks, message sending, and so on

We analyze the domain layer, and the core is to subcontract according to the domain, and provide DMO, VO, event and data access objects, with high cohesion within the domain and low coupling between the domains. For example, Domain1 corresponds to the contract subdomain, and Domain2 to the training subdomain.

2.6 Detailed Design

Now that the domain has been identified, it is time to divide tasks, with each team member responsible for one or more domains for detailed design. This stage is where familiar use-case diagrams, activity diagrams, sequence diagrams, database design, and interface design come in. It is important to note that domain-driven design is not a replacement for detailed design, but for clearer detailed design.

3 Article Summary

This paper discusses six issues that need to be paid attention to when DDD is landed, and analyzes six steps of landing through a case study of a football player information management system. In practical application, each business form may be different, but the methodology can be common, we need to make clear that the core of DDD is to divide and conquer, and with some tested effective methods for modeling, I hope this paper will be helpful to you.