Joined qunar domestic hotel quotation center team in August 2019, mainly responsible for quotation system development and architecture optimization. Have a strong interest in high concurrency and high availability, participated in the construction of remote multi-activity, and have a large number of daily order ten-million-level distributed system high availability construction experience. Like to study algorithms, ACM/ICPC programming contest twice entered the Asian region qualifier. Won the first prize in the first Hackathon Competition in Qunar.

1. Introduction

Domain-driven Design, or DDD for short, translates to domain-driven Design. This concept is an approach to system architecture design from a technical perspective. Online can find most of the data are basic technical perspective to illustrate, case are also listed in the code in the form of case, non-technical staff is very difficult to understand, and technical personnel to see, different technicians to understand the difference is very big, then at the time of landing system design often do not know how to start, sometimes feel DDD specific advantage of the, Even after some attempts fail, they may have a negative attitude towards DDD.

DDD is a design idea that deals with highly complex domains. It attempts to separate the complexity of technology implementation and control the complexity of the business by building domain models around business concepts to solve problems where software is difficult to understand and evolve. Therefore, DDD should focus on business remodeling, supplemented by system remodeling, and establish consensus and principles on business operation mode, system division and boundary within the team, while taking into account the scalability of future business development.

This article will combine the actual hotel quotation based on DDD thought reconstruction project, from the strategic design of DDD recommended (with the help of brainstorming etc to determine model, equivalent to confirm requirements), tactical design (specification, determine the architecture model and code is equivalent to confirm technical scheme), explaining DDD system realize three core stage its huge function in the whole process, It also involves the goals and outputs of each stage. I hope these practices can guide readers to some extent.

2. Reconstruct the background

Let’s take a look at the main process of quotation calculation before refactoring:

From the figure above, we can see that the business of the quotation system is quite complex. We can see a phenomenon: as long as the business related to “price” is coupled here, but different businesses have different meanings about “price”. Break it down from a business perspective:

As can be seen from these two figures, the quotation system does a lot of business that is not “price” and connects many different business teams. From the point of view of each team, when their business needs involve “price”, they naturally go to the quotation team, and each team only cares about whether their KPI is achieved and whether their needs are realized. The technical team can’t seem to refuse requests from the business, and every request seems reasonable (at least on the surface). The result is a hodgepodge of systems with the following problems:

  • The system is coupled to each other and different services invade each other, which makes maintenance difficult. Such as: Room is free flow displacement to the resources of the base price of 0, free room team if according to quote to the logic of the agents, quote don’t need to deal with, but the team need to consider the amount sold free room and the benefits of free room, is put forward to lower than the minimum reserve price agent 1 yuan, and other agents reserve is real-time calculated when the user requests, in order to achieve this logic, You’re going to hack into the logic of the quote
  • Low development efficiency, easy to step on the pit, the problem is not easy to troubleshoot. As a result of the business being left unaddressed and the various business teams working out their requirements, it is not clear how the coupled logic relates to each other. As a result, hidden pits can hardly be seen in the scheme stage, and can only be found in the development process. The ideal situation is that the demand changes when processing, the tragic situation is that the whole scheme changes, and the previous development is completely scrapped, and the cost is extremely high
  • The core business was invaded by marginal business, picking sesame seeds and losing watermelon. Quote core computing is often invaded by some edge of the business, the overall calculation of adjustment and adaptation, resulting in the core business and edge business mixed together, mutual influence, each adjustment to the relevant business out to discuss the impact and adaptation.
  • The process is too complex and the actual pricing strategy is affected.

Reasons for the above problems:

  • The requirements change quickly, the system involves many fields, the business logic is complex, and the system and the business field are not clearly divided.
  • The core reason is lack of business architecture and mature operating system. Systems are ultimately designed to support business and solve efficiency problems. If the business being supported is chaotic, the system is doomed to be dysfunctional. Due to the lack of stable operation process in the business, the responsibilities in the business division are not clear, and then the system division is not clear.

In order to effectively solve the above problem, we started based on the reconstruction of DDD thought, the core is: products and technologies, sitting together, discuss business play and reach a consensus, with the aid of the concept of “domain”, set up new to reshape their business model is complete, can satisfy the existing core business, and plan for future business development. In the process, delimit business boundaries and positioning, and then work together as domain experts to defend the domain and say no to unreasonable demands!

3. Strategic design stage of DDD ****3.1 Brainstorming: sorting and discussing with domain experts as the main part and technology as the auxiliary part

At this stage, the core role is that of the domain expert; prior to refactoring, it was primarily the product manager (PM) role. This stage to do a good job, like ordinary requirements, we briefly discuss, feasible plan to implement, this is not OK, easy to fall into DDD and DDD, the effect is not necessarily good. For the reconstruction based on DDD idea, we need to pay attention to the following [two premises] :

  • Deep understanding of the logic of core business operations. The product should be able to export the core business gameplay and future planning, so that the discussion can have a clear direction and the model can be developed to meet current needs and future adjustments.
  • Understanding the context of some of the existing business requirements. The product identifies some of the core business demands and the business play within the constraints of various factors such as the current architecture, so that it can be purposefully reconfigured and improved.

Here is a principle to note:

  • Business atomic principle, delimit business boundary; Avoid overlapping business responsibilities and over-coupling.

Also need to pay attention to [one method] :

  • Principle of extracting business atom: divide the business essence and find the method of business essence – divide the business based on the purpose of business development.

In this stage, the product can output real business style, including the core business style, temporary business style, etc., make the products and technology quickly reached a consensus on the understanding of the business, as discussed later linking the actual model, we can know the focus of the new model to solve the problem, extend to do well in that aspect. Take quotation as an example to illustrate the business gameplay of product output:

  • Three-party price limit: in the dimension of the hotel, apply to maintain the price range and guarantee the interests of the merchants.
  • Business promotion: EBK (large fixed activities, excellent enjoy, daily special, new customers), ES activities (short-term practical activities, Tanabata special), mainly for the user portrait packaging, meet the specific user identity or specific scene of marketing activities, get a lower base price, obtain higher profits.
  • Equity cloud: price unchanged, give more equity (delayed check-out, free breakfast, etc.).
  • Pay to sell: the settlement does not price, as long as it does not affect the settlement can, mainly by cashback, as far as possible to get the pricing power.
  • .

At the same time, in this stage, we should slim down the business, confirm the useless business, worthless business and some fuzzy business scenarios, and take them out together to see if they are still needed. The unnecessary ones should be removed first, so as to avoid the influence on the follow-up discussion model. Due to the long time of system iteration, this part requires technology to carefully comb the code, complement the relevant business scenarios and gameplay, make product decisions, whether to and future planning.

3.2 Model construction: solve the existing pain points and govern the messy process

At the heart of refactoring is the need to manage previously messy processes. In this process, pain points on the product side and technology side should be collected. When unifying the model, in addition to ensuring coverage and planning of business gameplay, existing technical and product pain points should be solved. This process is divided into two steps: abstraction and standardization.

  • ** Abstraction: ** Business abstraction of all business plays, starting with a primary merge, followed by an overall merge, merging similar business plays together as much as possible (analogies here to high cohesion in software architecture design). Below is an abstraction of the core gameplay of the product and technology during the discussion:

  • ** Standardization: ** Once you have an abstract process, you can consider standardizing the entire process. In the quotation reconstruction, after several discussions, we finally introduced the model and concept of spU-SKU and other e-commerce, and extracted the quotation extensible model. The core is to adapt personalized business to SKU (actually inventory unit, which can be likened to the general subdomain in THE CONCEPT of DDD), conduct standardized operations based on specific SKU, and then the new business play mainly carries out SKU adaptation. For business gameplay that is not yet supported, new attributes can be added to the SKU to define the processing of new fields. The business gameplay is highly extensible.

As can be seen from the figure above, the new quotation “fields” have been delimit, and the attributes and things to do contained in each “field” are also clear, from an original agent price to the final price shown to the user after processing, the whole process is also clear.

After these completion, the product side and the technical side have basically clarified the goals that can be achieved by this reconstruction: business remodeling (including slimming), technical architecture reconstruction, solving the existing pain points, and reaching a consensus on the business. In fact, at this time, the product and development have basically reached a consensus on most of the business, and it is obviously much easier to communicate. In the subsequent stages, the consensus is constantly strengthened and deepened.

4. Tactical design stage of DDD

The consensus model came out and began to enter the tactical design stage. The core of this phase is to determine the actual architectural patterns and code structure specifications based on the models discussed in the strategic design phase.

We adopt the popular layered architecture + clean architecture, which is divided into User Interface, Application Core and Infrastructure layers according to the structure recommended by DDD, as shown in the figure below:

In this layered architecture, we have confirmed responsibilities at each layer:

  • User Interface: quotation adaptation layer, used to adapt to different sources of personalized quotation requests, mainly reflects the ability to extend the quotation.
  • Application Core: quotation stability layer, quotation calculation engine, mainly reflects the Core computing power of quotation.
  • Infrastructure: quote base layer that encapsulates calls to external dependencies, including related components, systems, etc.

In this model, the “domains” of the Core quotation are all in the Application Core. According to the design of the previous domain model and combined with the actual calculation process and business form, we have made further refinement:

With the actual architectural model defined, start to determine the code structure specification. Our core internal requirements are: convention over specification, and take into account development habits. Specific as follows:

  • Not strictly follow DDD recommended code specification: the reason is that CQRS lack C(command), quote here is mainly calculation, no update operation.
  • Define the core domains and provide the related service methods without the need for an aggregate root (the delimit domains are used in a series when calculating the actual model).
  • Use a unified context throughout the calculation process.
  • Assurance level specification: distinguish the interface layer, application layer, and base layer.
  • Abstract the core quotation computation process, reuse the computation ability.

As for the choreography and visualization, it is mainly dealt with during the development process, and we will talk about it in detail during the development stage.

5. System implementation stage of DDD

At this stage, the core role has normally become the technology, but the product still needs to integrate the final model and the technology into the details of the actual process. Here is a separate quote here to do a good reference, the product is very responsible for the price calculation process of all the details of the documentation, the example of the example, the drawing of the drawing, is not only the core reference in the development process, but also after new learning to provide great convenience. The product is so serious, the development is not bad, the code design, the core process are also recorded through various charts, very practical. The documentation and diagrams produced at this stage of product and development are of particular potential value.

It is naturally easy to encounter some problems in the process of such large-scale reconstruction. Here are some core problems and countermeasures to be summarized:

  • New requirements adaptation: For developers, new requirements adaptation in the process may not be comfortable, but from another point of view, these requirements can be used to verify the adaptability of the model in advance, so that relevant personnel can see the effect of future completion at this stage, instead of worrying about the effect of online.
  • Fast delivery: The longer you delay, the easier it is to insert more demands and increase working hours, so you have to work overtime when necessary, not slowly.
  • Additional requirements: Before the refactoring, our automated cases were all at the interface level, which was a lot of trouble to verify. After the standardization of the new model process, the automated cases can be adjusted to the module level, which can make the automated cases more targeted and effective. Therefore, we reconstructed the automation case. Although it took a lot of time, it was good for the overall architecture to finish it once and it was worth it. After the automation case is transformed from the interface level to the module level, the overall case quantity is reduced to about 25% of the previous one, and the execution time of the automation case is correspondingly shortened a lot.
  • Planned manpower is taken away by other superior needs: All can not meet the accident, but really want to meet the still need to face actively, when we encounter this situation, the overtime is an unavoidable, at the same time, we coordinate the pace of the development and testing, to test to complete module into the test has been developed, and the function of the part can be set after tools (such as adaptation) after adjustment for measuring and testing in parallel. Through various coordination, we have solved this problem well.

Next, let’s talk about solving the pain points of everyday troubleshooting with visualization. We have also completely rewritten the troubleshooting tool, standardizing the quotation calculation process with the help of the new model, placing all the core data involved in the quotation calculation process into the total output of context debugging information for tool requests alone, and then rendering according to the module. So request, through tool interface can restore a quotation calculation every process, quickly get the quotation calculation core data, practical strong, such a simple tool on duty after the late online quotation not displaying problem directly fell by more than 90%, because everyone can easily through the tools to find out why. Of course, this tool is also highly maintainable, as shown in the figure below (with some core information hidden) :

This section leaves one choreographable problem. In the process of quotation calculation, due to the limitation of different channels and other factors, the calculation process involved is not exactly the same, so there is the possibility of capacity reuse and choreography. After finishing the process of different channels, we found that the main process and other process difference is bigger, and the process of different channels once will not modify, if to do dynamic scheduling may lead to failure instead, and if a new channel of basic 0.5 pd can be completed, so we can be arranged through code support, But no time has actually been invested in designing and completing the choreography feature to avoid being a figure-of-name.

After the completion of the development and verification, we gradually expanded the verification in accordance with the gray flow of designated hotels, designated hotels in small cities, hotels in popular cities, and hotels in full cities. The full release was completed within three days, and the whole process was smooth with no obvious problems.

6. Post-evaluation and summary

The reconstruction span was 3 months, and it took 1.5 months from the start of development to the full launch, which was one day earlier than expected. The actual internal effects will not be described here, but the feelings of all parties can be summarized separately:

  • Technical side: Fully learned the core gameplay of the business, rewrote the whole real-time calculation of the quote, standardized the whole calculation process, and mastered the calculation process and details of the core quote.
  • Product side: Based on the new architecture, it is easier to adjust the pricing strategy to meet business goals, and more focus is placed on optimizing the pricing strategy.
  • Operation side: the quotation calculation process is visualized, and the problem processing efficiency is improved.
  • Overall: more domain experts have been added, and we have a better understanding of the process and details of the business of quotation. It is much easier to communicate with each other and achieve the expected goals successfully.

Here’s a summary of DDD’s important role in this process:

  • Products and technologies sit together to sort out existing business and pain points, discuss business gameplay and future plans. Different from previous requirements and processes, conventional product requirements mainly start from business benefits and user experience, while conventional technical requirements mainly aim at technical optimization and solving some problems. This special demand can take into account the interests of both and future planning.
  • Help product define “territory”, define boundaries and responsibilities.
  • Help technology improve architecture and turn chaos into clarity.
  • At the same time, we can solve the technical pain points and upgrade the system architecture to achieve win-win situation.

DDD brings new ideas to core system refactoring, and hopefully more teams will use it and use it well