introduction
I believe that through the introduction of the previous articles, you have a certain understanding of DDD related theories and practical routines, but understanding DDD theory and practical means is one thing, can you apply these theoretical knowledge to our actual work? It's another matter, so this article walks you through all the theories and methods involved in the previous articles through actual business analysis. I want to use this method to let you experience the actual experience of DDD in the process of landing. What problems and how should we solve them.
Project Requirements Information
Here is the e-commerce scenario that everyone is more familiar with to explain, I think it will be easier for everyone to understand. Some time ago, on Double Eleven, everyone was dazzled by the various shopping coupon routines, as if they were not good at mathematics, and they did not deserve to get the best price. Everyone is complaining, so you can't do less routines, and give me 50% off when you buy things, won't the world be peaceful? I think the reason for this phenomenon is probably the involution of China's e-commerce industry. Only through the accumulation of various marketing activities can people spend more time browsing more products and get better customer retention. and transactions. Well, off topic, let's not care about these for now. So let's use this torturous coupon process as a design example today to illustrate the landing process of the entire DDD. The key business process of coupons is as follows: (1) When a big promotion is required, the operating students need to select the corresponding products, create and create coupons.
(2) Operating students need to create marketing activities, formulate corresponding marketing activity rules, such as what is full discount, cross-store discount is similar to this kind of rules that torture people's brain cells, and then associate the corresponding coupons, and finally submit the event for approval. After approval, the marketing campaign will be released.
(3) After submitting the activity for approval, the approval will be carried out for the marketing activity approval.
(4) After the user receives the coupon on the marketing page, after placing an order to purchase the product, the payment amount is calculated according to the corresponding coupon and the payment is completed at the time of payment.
After we have a general understanding of the background information of the DDD landing practice project, we will start the process of domain-driven design through DDD. In fact, it is not the ultimate goal for us to learn DDD theory and methods, but to achieve actual business complexity management and optimize microservice design through it is the real goal.
Strategic Design In the strategic design stage, our main process roughly 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 At this stage, all we do is to conduct a comprehensive business review, 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 method, event storm method and four-color modeling method. Here we use event storm to analyze and sort out business scenarios.
(1) Preparations in advance Before the event storm, we need to make some preparations, mainly including stickers, pens, and discussion rooms. It is best not to have chairs in the meeting room. The purpose is to let everyone stand together and concentrate on it. Have business discussions.
(2) Invite participants The participants in the conference mainly include business, users, PD, R&D, testing, architects, etc.
(3) Business discussion First determine what the business we need to discuss today and what the goal is. As mentioned above, the business discussed this time is the coupon business of marketing activities. The goal is to complete the business carding of coupons, ensure that there is no gap in business understanding, and achieve consistency in business understanding among the team. In this process, we need to drive communication by asking questions.
a. Analyze the events in the business and find out the causes and consequences of the events. What does it mean? That is, what action will lead to the occurrence of the current time, and what consequences will be caused after the current event occurs. We need to sort out these things. One more thing to note, I want to focus not only on normal business processes but also on abnormal business processes.
b. Look for business logic and business rules. For example, before submitting an event, we need to determine who these coupons are applicable to, how to receive them, and how to take effect. These are all things we need to determine before performing operations. Business Rules. As shown in the figure below, we have sorted out the business process of coupons, and described the entire process of coupon business circulation from the perspective of operators, events, and commands.
Note: In the process of event storm, all participants must devote themselves to the whole process, put down their mobile phones and computers, and participate in the entire business sorting process together. Only in this way can the event storm have a better effect.
2. Domain modeling In the previous event storm business review, we have comprehensively sorted out the participants, actions, and events involved in the coupon business. Then we have to do domain modeling on this basis, which is the core of the entire 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 operations around them. According to the analysis, we have extracted entities such as coupons, marketing activities, activity approval forms, activity rules, and approval comments, as well as value objects and command operations related to these domain objects in the entire business process.
(2) Building a business aggregation After completing the domain object analysis, we need to build a business aggregation. To build an aggregate, first find the aggregate root in the entity. Let's first review the characteristics of the aggregate root. The aggregate root must be an entity, so it has a globally unique identifier. In addition, it has a life cycle and requires a special module to manage it. According to this standard, in the domain objects, we found that coupons, marketing activities and activity approval forms have the characteristics of aggregation root, while marketing rules, marketing content, etc. are closely related to marketing activities, so they constitute the aggregation relationship of marketing activities. Coupon rules, coupon types, etc. are closely related to the coupon aggregation root, so they constitute a coupon aggregation relationship. In the same way, the activity approval form also constitutes an aggregation relationship. Finally, we form the following aggregation relationship.
3. Divide the boundary context In the above steps, after we have obtained all the aggregations in the entire business process, we need to divide the specific aggregations into the corresponding contexts with more business semantic context, so we can divide the business of coupons into Coupon, Campaign, and Approval are three bounded contexts.
Tactical Design In the strategic design stage, we have used the event storm method to sort out the entire business, and at the same time, we have built a domain model and divided the boundary context. Then we need to map the domain model to the engineering structure and code to achieve the final implementation. In addition, there are actually many details that need to be clarified at this stage. For coupons, which attributes does it contain, 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. down.
1. Microservice splitting According to the already divided boundary context, we can split it into three microservices: coupon service, marketing activity service and approval center. As for user payment and use, it is still done by the existing payment service. , it is only necessary to use the coupon for the final amount calculation when the payment is calculated.
2. Domain layering In terms of domain layering, we still follow the layered structure mentioned in the previous article, namely 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 read the introduction in the previous article, and I will not repeat it here. Taking coupons as an example, the objects in the actual aggregation need to be further refined. For coupons it actually has a value object as shown below and entities to make up the actual coupon. At the same time, the field services we sort out for coupons also include creating coupons, querying coupons, and modifying the status of coupons. These actions should actually be implemented at the domain layer in the form of domain services. The corresponding biz layer is equivalent to the orchestration and combination of business, that is, the concatenation of actual business processes.
3. Code structure After we further refine the domain objects and finalize the corresponding domain services, we can map the analyzed content into the layered code of the project. As shown in the figure below, it is the code mapping of 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, code writing and functional testing. Especially in the detailed design stage, we still need to finalize a lot of details, such as database tables. Design, such as what MQ to use, whether to use cache, how to ensure data consistency between cache and database, and whether distributed services have distributed transaction problems, and how to solve them? Is there a service idempotency problem and how should it be solved? These need to be determined during the detailed design phase. Therefore, DDD is like a framework, through which business is mapped into domain objects, domain services and domain events, and then these domain-related content is re-read and mapped into actual code. It makes our service more logically clear and more scalable, but we still need corresponding solutions to solve the details of distributed technical implementation.
Summarize
This article uses the issuance and use of coupons in the marketing activities of the e-commerce industry as an actual case to illustrate the process of DDD field-driven design implementation. According to this way of thinking, combining the respective business characteristics in actual work should be able to truly complete the practice of the entire DDD. Everything is difficult at the beginning. I believe that as long as everyone can personally participate in or lead a DDD implementation process, then the understanding of the DDD architecture design methodology will enter a new level. In the following articles, I will talk to you about some problems that may be encountered in the process of implementing DDD and the problems of software complexity management.