introduction
Through the introduction of the previous article, I believe that everyone has a preliminary understanding of what DDD is, and knows that it is a microservice architecture design methodology, which provides direction and guidance for us on how to establish a domain model and how to realize microservice division. But as for how to use DDD specifically, you may still be in a state of ignorance, so starting from this article and subsequent articles will explain in detail how to implement DDD. Some important concepts in DDD will still be involved in this. I originally wanted to introduce all the concepts in an article, but I think that the concept will only impress everyone when it should appear, otherwise these The concept is just a rigid concept, we don't know why it appears and what problems it can solve.
The general implementation process of DDD
As shown in the figure below, the implementation of DDD generally needs to go through three stages, namely, business analysis-"strategic design-"tactical design , and the output of different stages is the input of the next stage. The business analysis phase outputs business events, business logic, and business classification described in a unified language for strategic design, while the strategic design phase inputs domain models and boundary contexts for the tactical design phase to facilitate microservice splitting and model mapping. Let's take a look at what these three stages have done.
Business analysis: At this stage, it is necessary to gather members of the project team, mainly including domain experts, designers, developers, etc., to conduct a comprehensive review of the business problem domain and business expectations, to find a unified language in the business, and to discover in the business domain Domain events, domain objects and their corresponding domain behaviors, and figure out their respective relationships.
Strategic design: through the theory of DDD, divide the business domain to build a domain model, sort out the corresponding bounded context, and use a unified domain language to divide the domain from the strategic level and build a domain model. In the process of building a domain model, it is necessary to sort out the corresponding aggregates, entities, and value objects.
Tactical design: take the domain model as the input of tactical design, use the bounded context as the boundary of microservice division to split microservices, perform domain layering in each microservice, and realize the mapping of domain model to code, so as to realize the implementation of DDD Real implementation.
Supplementary related concepts
Before introducing strategic design and tactical design, let's clarify some obscure conceptual content, which always seems to be unclear. I think one of the reasons why DDD is not easy to get started is that these concepts are too difficult to understand, even the description in the original book "Domain-Driven Design: Coping with Software Core Complexity" is even more elusive. To understand these conceptual contents, we need to think about why such a concept exists, what problems it appears to solve, and how it is used in the actual context. I think this is the only way we can understand these unclear Dongdong can have a deeper understanding. I will try my best to illustrate with some examples to facilitate your understanding.
1. Value object
The value object seems to be a relatively abstract concept. The more abstract the concept, the more we need to grasp the main context to understand it. As far as the value object is concerned, we can understand it as something without an ID. What does it mean without an ID? It can be understood that when we eat out and choose a seat in the restaurant, do we care where the table is generated, what is the code and what is the specification? Obviously not, as long as there is space available. Of course, we still need to pay attention to the context of the value object. As in the example just now, our consumers don’t care which seat to sit in, but the merchant does, because he needs to serve dishes and collect bills according to the table number.
Let's give another example. When we design user information, it will include the user's address. The user's address is actually determined by which province, city, and county the user is from, what the specific address is, and what the zip code is. What and so on attribute information, then this address information is actually a value object in the user information, and it does not need a unique ID to identify it.
2. Entity
Different from value objects, entities are uniquely identified, which is like each of us will have an ID card, and the ID number on the ID card is the unique identification of each person. In addition, this ID number will always follow us and will not change. Even if you change your name and account status, the ID number will not change. This is another feature of the entity that it has continuity. Entities correspond to the business attributes and business behaviors of business objects.
Both value objects and entities are domain objects in the domain model, which are the basic elements that make up the domain model, and together realize the most basic core domain logic in the domain.
3. Polymerization
It is another concept that seems difficult to understand. In fact, in plain language, if people are different business entities, then different organizations and institutions in society are to bring people with corresponding skills together to play a greater role. A collection of business values and more complex business behaviors. This is like having various departments in our company, the human resources department is responsible for recruitment and compensation, the sales department is responsible for marketing, and the R&D department is responsible for product development. Different departments are actually different aggregates. Aggregation is a collection of entities with business relationships and value objects. We can understand it as aggregation by aggregating entities, value objects, and business logic between them to complete a certain business node. We can divide the aggregation according to the single responsibility of the business and the original design of high cohesion.
4. Aggregate root
The emergence of aggregation is actually a kind of business unit, so it must involve data persistence. If any entity in the aggregation can be modified by the outside, then it will be difficult for us to ensure the data consistency in the aggregation. Therefore, we need a unified entry for data input and modification to ensure that the data modification in the aggregation conforms to the business rules in the aggregation, so the concept of aggregation root appears. An aggregate root is actually an entity with a unique identifier and an independent life cycle. But he is a special entity, he has the function of coordinating entities and value objects to complete business logic, just like the person in charge of a department. An aggregate has only one aggregate root. The aggregate root organizes and coordinates entities and value objects in a reference-dependent manner within the aggregate. The aggregate root and the aggregate root use unique ids to coordinate between aggregates.
strategic design
The words "strategic design" sound a bit lofty, and feel far away from my DS. In fact, no matter for a company or an individual, there needs to be a development goal and guidelines to guide us where we should go. We can call this guiding content a strategy. Then in the DDD field, strategic design mainly starts from the business point of view, divides the domain boundary of the business, establishes a bounded context based on the common language and the semantic boundary of the business context, and realizes the construction of the business domain model. The bounded context can be used as the boundary of microservice splitting and design. Because we must first have a domain model and context with clear boundaries, we can design microservices with clear boundaries. Therefore, the most important thing in the strategy design phase is bounded context and domain modeling.
Usually in the business analysis stage, we sort out and analyze the main process of the business domain, and define business expectations at the same time. In the process of strategic design, it is necessary to comprehensively sort out the business domain. First, segment the business domain, divide the business context boundary, and then establish the corresponding boundary. The domain model in the above, context boundary and domain model can be done It is an input for the split design of microservices, and guides the split design of microservices when they are implemented. Among them, in the business, the corresponding domain model is very important. So what method should we adopt to build a domain model with high cohesion and low coupling from complex business domains? We can realize the construction of the domain model through two stages of business analysis and domain modeling.
1. Business analysis
A. Event storm
The event storm method can be used to quickly analyze and decompose complex business domains, and analyze and extract corresponding domain models. The event storm was proposed as early as 2013, by organizing domain experts and project team members to brainstorm together, and sorting out all domain events in the business domain, as well as participants and inputs of domain events.
participant
It mainly includes domain experts, DDD experts, architects, product managers, project managers, developers, and testers.
practical activity
After gathering the participants, everyone needs to sort out the current business domain issues through brainstorming . For example, whether a certain business action or behavior will trigger the next business action, what is the input and output of this action (domain event), who (entity) issued what action (command), and triggered this action, all of which we need Sort it out.
Let's take the e-commerce system that everyone is most familiar with as an example. An important link in the e-commerce business is logistics. Therefore, logistics is an important business subdomain of e-commerce business. After the user places the order, Chen Cheng’s corresponding cargo picking list is required in the warehousing field. The system generates corresponding picking tasks for the warehouse operators in different partitions according to the goods in the picking list. The task picks up the goods and puts them into the corresponding goods container. Finally, after the picking is completed, all the order items are merged, verified, and finally formed into a package before the subsequent delivery process.
Then in this process, the entities we will involve include orders, picking lists, picking tasks, users, containers, etc. , and the corresponding value objects are address information . Domain events are picking list generation and picking task generation.
2. Domain Modeling
In my opinion, domain modeling is actually the most important part of the entire DDD domain-driven design. Yes, a good domain model shows that the business process is sorted out and the abstraction of the business domain is done well. Next, a domain model with high cohesion and low coupling can directly determine the quality and level of microservice design.
A. Find entities and value objects
After a comprehensive business sorting, we can find the corresponding entities and value objects in the business objects, which will involve which domain objects are designed as entities and which domain objects are designed as value objects. It mainly depends on the actual business characteristics.
B. Build aggregation
Through business sorting, we found all entities and value objects under the business, and then we will build aggregation. Before building an aggregation, we need to find the aggregate root from the entity collection. This is like capturing the king first when fighting a war. After the king is captured, the soldiers below will obey.
So how should we judge that an entity is an aggregate root? It mainly depends on whether the entity has a dedicated module for maintenance, whether it has a complete independent life cycle, and whether it has a global unique ID. Through these judging conditions, we can easily find the corresponding aggregate root. As shown in the figure below, the task of performing operations in the warehouse, in which the picking list is an aggregate root, meets the above conditions, and at the same time, it can be related to it. Business-related entities such as goods and picking containers are merged into picking lists, and finally form picking aggregation.
C. Divide aggregation into bounded context
First of all, we need to list all the domain events sorted out before and the trigger commands of event flow. In this process, we extract the objects that generate business behaviors, which are the entities mentioned above. As mentioned above, the logistics domain, inventory, container. In this process, we need to find the corresponding entities and value objects, and at the same time find the aggregate roots in these entities, and divide the aggregate roots, entities, and value objects with close business logic relationships together to form aggregates, and then divide according to the previous The Bounded Context divides multiple aggregates into a Bounded Context.
tactical design
Different from the high-level strategic design, tactical design starts from the actual technical point of view. It focuses more on the technical realization of the domain model, and completes the development and implementation of microservices according to the domain model. In a sense, strategic design is actually the input of tactical design. In the tactical design, there will be code implementations of aggregation, aggregation root, entity, value object, domain service, and domain event, and the design and system implementation will be realized by mapping these domain objects into the code. At this stage, we need to sort out the boundaries of microservices and the domain objects within the boundaries and the relationships between them, and we can actually determine which code modules these domain models are in and the specific positions in the microservice layering.
Through DDD, the business domain is subdivided according to certain rules. Yes, the scope of the problem can be limited to the specified boundary, so we can establish a domain model within this boundary, and then implement the domain model through code to solve the corresponding business problems. .
Therefore, in the tactical design stage, we have an important task to complete, one is the domain object analysis and boundary division of microservices, and the other is the structural layering of microservices.
1. Microservice domain object analysis and boundary division
In the strategic design phase, we have built a business domain model that includes entities, value objects, and aggregate roots. In the above, we have actually divided the aggregation according to some business domains, so here we need to continue to divide the microservices according to different aggregations and existing bounded contexts. Some microservices will contain multiple aggregates, and some microservices will have only one aggregate.
2. Layered microservice structure
In the traditional engineering code structure, most of them adopt the MVC engineering structure. But with the advent of the microservice era, the traditional engineering structure cannot meet rapidly changing business needs. In addition, with the implementation of DDD domain-driven design, it is necessary to further evolve and upgrade the engineering structure of microservices.
Eric Evans proposed the traditional four-tier structure in the article "Domain-Driven Design: Coping with Software Core Complexity", but there are actually certain problems. In DDD domain-driven design, the domain layer should be the core layer, but the base layer is in the core position in the traditional four-layer structure, which is a bit of an upside-down feeling. Therefore, a new four-layer structure with the domain layer as the core should be adopted to optimize the original structure and realize the decoupling of the base layer.
Basic layer: In fact, it provides basic general technical support for other layers of microservices, such as Redis, MQ, and databases. It is common that database persistence can be placed in this layer.
User interface layer: responsible for displaying information to users and transforming user request intentions. At the moment when the front-end and back-end are separated, it can realize the role of adapting different user front-ends without changing the back-end services.
Application layer: It can be understood as the realization of domain objects and multiple aggregated service orchestration and composition, and there should not be too much business logic.
Domain layer: The domain layer is actually the core of the entire microservice, which involves state changes of domain objects and domain rules. The domain layer mainly includes entities, value objects, aggregate roots, and domain services.
Of course, there are actually other hierarchical structures such as five-layer hierarchical structure and hexagonal hierarchical structure.
Summarize
This article mainly focuses on the three major processes of the DDD domain-driven design landing time, and details the input and output of the strategic design phase and the tactical design phase.