Shulou(Shulou.com)05/31 Report--

This article mainly explains "what are the six problems and steps of DDD modeling". The content of the explanation is simple and clear, and it is easy to learn and understand. Please follow the editor's train of thought to study and learn "what are the six problems and steps of DDD modeling".

1 six questions 1.1 Why to use

The core of DDD methodology is to decompose the problem into small problems, big problems into small problems, large business into small areas, in short, divide and rule, one by one.

Divide-and-conquer means that we have no way to start with large business directly, and we need to decompose it into small areas with high cohesion, so that the boundaries of the business are clear, and these small areas are what we have the ability to deal with. this is the core of domain-driven design.

One by one means that when the problem is divided into small domains, because the small domain business is cohesive and its sub-domains are highly related, we can design them in detail in the technical dimension and divide the project according to the domain in the management dimension. It should be pointed out that DDD is not a substitute for detailed design, DDD is for more clear detailed design.

In the Internet industry where micro-service is popular, when the business is becoming more and more complex, technicians need to solve the problem of how to define the boundary of micro-service. DDD, which is a feature of clarifying the business boundary, can be used to solve this problem.

1.2 methods and objectives

Our goal is to draw clear boundaries for our business, and DDD is one of the effective ways to achieve our goals, which requires special attention. DDD is a method, not a target, and does not need to be used for use. For example, businesses with relatively simple business models that can be easily analyzed do not need to use DDD, and there are some projects that aim to quickly verify the type of projects, which are 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 subdomains, and a subdomain can be divided into multiple subdomains, and the bounded context is essentially a subdomain, so in the process of business decomposition, is a business module a domain, a subdomain or a subdomain?

I don't think we need to dwell on this issue, because it depends on the point of view of the module. You think the whole may be someone else's part, the part you think may be someone else's whole, it doesn't matter what the name is, the most important thing is to converge the highly relevant modules of the business in accordance with the principle of high cohesion.

1.4 coarse and fine grain size

There is no unified standard for the granularity of business division, which should be considered comprehensively according to business needs, development resources, technical strength and other factors. For example, splitting micro services too small will increase the complexity of development, deployment and maintenance, but too rough splitting may lead to a large number of business highly coupled, development and deployment is very fast, but the lack of maintainability and scalability, this needs to be weighed according to the actual situation.

1.5 domains 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, let's first discuss the set of concepts of entities and value objects. An entity is an object with a unique identity, which is accompanied by the entire life cycle of the entity object and cannot be changed. A value object is essentially a collection of attributes and does not have a unique identity.

Domain objects not only contain value objects, but also retain the business meaning of value objects, while data objects can use a more loose structure to preserve 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, plus a unique number can correspond to the physical object. The running distance, the success rate of passing and the number of goals are the performance of the players in the game, and the set of these attributes can correspond to the value object.

Value objects can be stored in loose data structures, 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:

/ / data object

Public class FootballPlayerDO {

Private Long id

Private String name

Private Integer height

Private Integer weight

Private String gamePerformance

}

/ / Domain object

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

}

1.6 abstraction and implementation

The core of abstraction is to find the same and extract common factors from different things. The core of the implementation is to find differences and expand their respective attributes and characteristics. For example, the template method design pattern is to build the framework with abstraction and extend the details with implementation.

Going back to the discussion of the data model, we can see that scripting is a way to expand flexibility, not only by using groovy and QLExpress scripts to enhance system flexibility, but also by loose and extensible data structures. The data model abstracts the basic attributes such as name, height and weight. For the frequently changing game performance attributes, the values of these attributes may change frequently, and even the attributes themselves may 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 always has to fall to the ground, and landing also requires some steps and methods. In this paper, we analyze a football player information management system, the goal is to manage players from the transfer to the last game of the whole link information, this system should not be touched, let's analyze it together. It needs to be explained that this example focuses on how the DDD methodology falls to the ground, and the business details may not be comprehensive.

2.1 process carding

There are two issues to consider in the carding process. The first question is from what perspective to sort it out. Because different people see different processes. The answer depends on what the system needs to solve, because we have to manage the entire link information from the transfer to the game, so it is an appropriate choice from the athlete's point of view.

The second question is what if you are not familiar with the business? Because we are not sports and sports experts, we do not know the business details of the whole link. The answer is that there must be business experts present when combing the process, because there are no real business details and domain-driven design is impossible. By the same token, when combing complex business processes on the Internet, there must be product managers or operators who are familiar with the relevant business.

Suppose the football business experts sort out the business process, the players propose a transfer, agree to go to the new club for a medical examination, and sign the contract after passing the physical examination. After entering the new club, train, play the game after reaching the training target, and attend the press conference after the game.

2.2 four-color modeling (1) time scale object

The first color of four-color modeling is red, which represents the time scale object. Time scale object is the most important object in four-color modeling, which can be understood as the core business document. In the course of the business, we must leave documents for the key business, through these documents can be traced back to the entire business process.

The time scale object has two characteristics: the first is the fact immutability, which records the facts that occurred at a certain time point or time period in the past. The second is the traceability of responsibility, which records the information that managers pay attention to. Now we analyze what the system time scale objects are and what core business documents need to be left behind.

Transfer documents corresponding to transfer documents, physical examination documents corresponding to medical examination documents, contract documents corresponding to signing contracts, training documents corresponding to training documents, competition documents corresponding to competition indicators, press conference documents corresponding to interview documents. Draw the following time scale objects according to the analysis:

(2) participants, lands and objects

These three kinds of objects are represented in green in four-color modeling, and we take the e-commerce scene as an example. When the user pays for the merchant's goods, the user and the merchant are the participants. When the logistics system delivers goods, the distribution document needs to have the delivery address object, and the address object is the ground. Orders need objects of goods, logistics and distribution need goods, goods and goods are things.

When we analyze this example, we can see that the participants include the general manager, team doctor, coach, fans, journalists, training address, match address, interview address, signed jersey and signed football:

(3) role object

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

(4) description object

We can add relevant description information to the object, which is represented in blue in four-color modeling:

2.3 Division of areas

In the process of four-color modeling, we realize that the time scale object is the most important object, because it carries the core documents of the business system. When dividing the domain, we can not do without the time scale object, and divide the domain by converging the relevant time scale object.

2.4 Domain events

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

For example, if a player is injured in a game, this is a game sub-domain event, but the medical and training sub-domain needs to be perceived, then the game sub-domain sends out an event, and the medical and training sub-domain will subscribe.

For example, the player scores a goal in the game, which is also a game sub-domain event, but the training and contract sub-domain will also pay attention to this event, so the game sub-domain will also issue a game goal event, and the training and contract sub-domain will subscribe.

One problem to note through event interaction is that business implementation through event subscription can only adopt final consistency and need to give up strong consistency, which may introduce a new complexity tradeoff.

2.5 Project Construction (1) API

Interface layer: provides external interface declarations and DTO objects

(2) controller

Access layer: provides access to HTTP

(3) service

Business layer: both the domain layer and the business layer contain business, but for different purposes. The business layer can combine different domain businesses, and can add flow control, monitoring, logging and permission control aspects, which is richer than the domain layer and provides BO objects.

(4) domain

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

(5) dependency

External access layer: invokes external RPC services in this module, parses the return code and returns data

(6) infrastructure

Basic layer: contains 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, data access objects, high cohesion within the domain, low coupling between domains, for example, domain1 corresponds to the contract sub-domain, domain2 corresponds to the training sub-domain, and domain3 corresponds to the contract sub-domain.

2.6 detailed design

So far, the domain has been identified, and now tasks can be divided according to the domain, and the members of the group are responsible for the detailed design of one or more domains. This stage is very familiar with use case diagrams, activity diagrams, timing diagrams, database design, interface design opportunities. It should be noted that domain-driven design is not to replace detailed design, but for more clear detailed design.

Thank you for your reading, the above is the content of "what are the six problems and steps of DDD modeling". After the study of this article, I believe you have a deeper understanding of what the six problems and steps of DDD modeling are, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.