Shulou(Shulou.com)06/01 Report--

This article mainly shows you the "sample analysis of dismantling DDD in Java", which is easy to understand and clear. I hope it can help you solve your doubts. Let me lead you to study and study the "sample analysis of dismantling DDD in Java".

Project requirements information

Here or we are more familiar with the e-commerce scene to explain, I think it is easier for everyone to understand. In the Singles Day holiday some time ago, everyone was dazzled by the routines of all kinds of shopping coupons, as if they were not good at math and didn't deserve to get the best price. Everyone is complaining, so can't we have less tricks and give me a 50% discount on shopping? wouldn't the world be peaceful? I think the reason for this phenomenon is probably the internal volume of China's e-commerce industry. Only through the accumulation of various marketing activities can we spend more time browsing more products and get better visitors and transactions. All right, let's get off the subject. Let's not worry about that for now. Today, let's use this excruciating coupon process as a design example to illustrate the landing process of the whole DDD. The key business processes of coupons are as follows:

(1) when great promotion activities are needed, operators need to select the corresponding products and create coupons.

(2) Operation students need to create marketing activities and formulate corresponding marketing activity rules, such as full reduction, cross-store reduction and similar rules that torture human brain cells, then associate the corresponding coupons, and finally submit the activity for approval. After the examination and approval, carry on the marketing activity release.

(3) after the activity is submitted for approval, the approval shall be carried out for the examination and approval of the marketing activity.

(4) after the user receives the coupon on the marketing page, after issuing an order to purchase the goods, the user calculates the payment amount and completes the payment according to the corresponding coupon at the time of payment.

Practice of DDD landing

Once we have a general understanding of the background of the project, we should begin the process of domain-driven design through DDD. In fact, our ultimate goal is not to learn the theory and method of DDD, but to achieve the actual business complexity governance and optimize the design of micro-services through it.

Strategic design

In the strategic design stage, our main process includes three stages: business scenario analysis, domain modeling and boundary context division. In fact, strategic design is a core step in the DDD process.

1. Business analysis

All we do at this stage is to conduct a comprehensive business carding, sort out all the details involved in the business, and provide sufficient and comprehensive business input for subsequent domain modeling and analysis. The frequently used business scenario analysis methods mainly include use case analysis, event storm and four-color modeling. Here we use event storms to analyze and sort out business scenarios.

(1) preparation in advance

Before the event storm, we need to make some preparations, including stickers, pens and discussion conference rooms, it is best not to have chairs in the conference room, so that everyone can stand together and concentrate on the business discussion.

(2) people invited to the meeting

The participants in the meeting mainly include business, users, PD, research and development, testing, architects and so on.

(3) Business discussion

First of all, determine what the business we need to discuss today is and what the goal is. As mentioned earlier, the business discussed in this paper is the coupon business of marketing activities, and the goal is to complete the business carding of coupons, to ensure that there is no business understanding of gap, and to achieve consistency of business understanding in the team. In this process, we need to drive communication by asking questions.

A. what does it mean to analyze the events in the business and find out the causes and consequences of the events? It is what action will lead to the occurrence of the current time, and what will be the consequences after the occurrence of the current event. We need to sort out all these. It is also important to note that I should focus not only on normal business processes but also on abnormal business processes.

B, look for business logic and business rules, for example, we need to determine who applies to these coupons, how to get the coupons and what the effective events are before we submit the activities. these are the business rules that we need to determine before we perform the operation.

As shown in the following figure, we sort out the business process of the coupon and describe the whole business flow process of the coupon from the way of operator, event and command.

Note: during the event storm, all participants should devote themselves to the whole process, put down their phones and computers, and participate in the whole business carding process together. only in this way can the event storm have a better effect.

2. Domain modeling

In the previous event storm business carding, we have comprehensively combed the participants, actions and events involved in the coupon business. Then we will do domain modeling on this basis, which is the core of the whole DDD.

(1) Domain object analysis

As shown in the event Storm blackboard above, we need to find the corresponding entities, value objects, and domain events and command actions around them. According to the analysis, in the whole business process, we extract entities such as coupons, marketing activities, activity approval orders, activity rules, approval opinions, as well as value objects and command operations related to these domain objects.

(2) build business aggregation

After completing the domain object analysis, we need to build the business aggregation. If you want to build an aggregation, you must first find the aggregation root in the entity. Let's first review the characteristics of the aggregation root, the aggregation root must be an entity, then it has a globally unique identity, in addition, it has a life cycle and needs special modules to manage. According to this standard, among the domain objects, we find that coupons, marketing activities and activity approval forms have the characteristics of aggregation root, while marketing rules, marketing content and so on are closely related to marketing activities. therefore, they constitute the aggregation relationship of marketing activities. Coupon rules, coupon types and so on are closely related to the root of coupon aggregation, so they form a coupon aggregation relationship. The approval document of the same activity will also form an aggregation relationship. In the end, we form the following aggregation relationship.

3. Dividing the boundary context

In the above steps, after we have obtained all the aggregations in the entire business process, we need more business semantic context to divide the specific aggregations into the corresponding contexts. therefore, we can divide the business of coupons into three bounded contexts: coupons, marketing activities, and approval.

Tactical design

In the strategic design stage, we sort out the whole business through the event storm method, and construct the domain model and demarcate the boundary below. Then we will map the domain model to the engineering structure and the final implementation implementation in the code. In addition, there are actually many details to be clarified at this stage. In terms of coupons, which attributes are included, which domain services are required, which need to be designed as entities, and which need to be designed as value objects, these need to be clarified in the tactical design stage.

1. Micro-service split

According to the boundary context, we can split it into three micro-services: coupon service, marketing campaign service and approval center. As for the user's payment, it is completed by the existing payment service, but the coupon needs to be used to calculate the final amount in the payment accounting.

2. Domain layering

In terms of domain layering, we still follow the hierarchical structure mentioned in the previous article, that is, interfaces layer, biz layer, domain layer and instructure layer. The meaning of each layer has been explained in detail in the previous article. You can refer to the introduction in the previous article. I will not repeat it here.

Let's take coupons as an example, the objects in the actual aggregation need to be further refined. For coupons, it actually has the value objects and entities shown below to make up the actual coupons. At the same time, our combing services in the area of coupons also include creating coupons, querying coupons and modifying the status of coupons, all of which should actually be landed in the form of domain services at the domain level. The corresponding biz layer is equivalent to the orchestration and combination of business, that is, the series of actual business processes.

3. Code structure

When we further refine the domain objects and finalize the corresponding domain services, we can map the analyzed content to the layered code of the project. As shown in the following figure, this is the code mapping for the domain layer of the coupon.

Of course, this does not mean the end, in fact, there is still a lot of work to be done in the follow-up, such as detailed design, coding and functional testing, especially in the detailed design stage, we also need to finalize a lot of detailed issues, such as the design of database tables, such as what MQ to use, whether to use cache or not, and how to ensure the data consistency between cache and database. Is there a problem of distributed transactions in distributed services, and how to solve it? Is there a problem of idempotence of service? how should it be solved? All these need to be determined in the detailed design stage. So DDD is like a framework through which business is mapped into domain objects as well as domain services and domain events, and then these domain-related content is reread and mapped into actual code. Make our service more logical and scalable, but the details of distributed technology implementation, we still need to have a corresponding solution to solve.

The above is all the contents of the article "sample Analysis of dismantling DDD in Java". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

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.