The introduction

Through the introduction of the previous articles, I believe that you have a preliminary understanding of what is DDD, know that it is a microservices architecture design methodology, for us to solve how to establish domain model, how to achieve microservices division provides direction and guidance. However, you may still be confused about how to implement DDD, so this article and the following articles will explain how to implement DDD implementation in detail. In it will involve some important concepts of DDD, originally thought all about concept in an article, but I think, the concept is always when it should appear to impressed everyone, otherwise these concepts are just the concept of rigid, we don’t know why he appeared and can solve any problem.

DDD implementation process

As shown in the following figure, the implementation of DDD generally needs to go through three stages: business analysis, strategic design, and tactical design. The output of each stage is the input of the next stage. In the business analysis stage, business events, business logic and business classification described by unified language are output for strategic design. In the strategic design stage, domain model and boundary context are input for tactical design stage to facilitate microservice decomposition and model mapping. Let’s take a look at what happens in each of these phases.

Business analysis: need to collect at this stage of the project team members including the domain experts, designers and developers expect to conduct a comprehensive of the problem domain and business with the comb, li please unified language of business, found in the areas of business areas events, objects and its corresponding field behavior, find out their relationship.

Strategic design: based on THE theory of DDD, the business domain is divided and the domain model is built, the corresponding bounded context is sorted out, and the domain is divided and the domain model is built from the strategic level through the unified domain language. The corresponding aggregates, entities, and value objects need to be sorted out during the construction of the domain model.

Tactical design: The domain model is taken as the input of tactical design, and the bounded context is taken as the boundary of microservice division to split microservices. Domain stratification is carried out in each microservice to realize the mapping of domain model to code, so as to realize the real implementation of DDD.

Related concepts supplement

Before we get into strategic and tactical design, let’s clear up some of the arcane concepts that often seem obscure. One of the reasons I think DDD is so hard to get started with is that the concepts are so hard to understand, even in the original Domain-Driven Design: Solutions to Software Core Complexity. To understand these conceptual contents, we need to think about why such concepts exist, what problems they are created to solve, and how they are used in actual contexts. I think only in this way can we have a deeper understanding of these obscure things. I try to combine some examples to illustrate, convenient for everyone to understand.

The value object

Value objects seem to be abstract concepts, and the more abstract a concept is, the more we need to grasp the most important context to understand it. In terms of value objects, we can interpret it as something without ID. What does it mean to have no ID? It’s understandable that when we eat out and choose a table in a restaurant, do we care about where the table was created, what the code is and what the specifications are? Obviously not, as long as there’s an empty seat. Of course, we still need to pay attention to the value object context. For example, we consumers do not care about which seat we sit, but the merchant does, because he has to serve food and collect the bill according to the table number. Comes back to you as an example, when we design the user information, which will include a user’s address, the address of the user is actually by the user is which province, which city, which county of what is and what is the specific address, zip code, and so on of attribute information, then the address information is actually a value object in the user information, He doesn’t need a unique ID to identify him.

entity

Unlike value objects, entities have unique identifiers, just as each of us has an ID card, and the ID number on the ID card is the unique identification of each person. The other thing is that the ID number stays with us and it doesn’t change, even if you change your name the status of your account changes, the ID number doesn’t change, and that’s another feature of the entity is that it has continuity. Entities correspond to business attributes and business behaviors of business objects.

Value objects and entities are the domain objects in the domain model, which are the basic elements of the domain model. Together, they realize the most basic core domain logic in the domain.

The aggregation

Another concept that seems difficult to understand. In fact, in plain English, if people are different business entities, then different organizations and institutions in the society are collections of people with corresponding skills to play greater business value and complete more complex business behaviors. It’s like we have different departments in our company. We have hr for hiring and compensation, sales for marketing, and R&D for product development. Different sectors are actually different aggregations. Aggregation is a collection of business related entities and value objects, which can be understood as aggregation to achieve a certain business node through the aggregation of entities, value objects and business logic between them. We can divide the aggregation based on the single responsibility of the business and the high cohesion of the design.

Aggregate root

The emergence of aggregation is actually a business unit, which must involve the persistence of data. If any entity in the aggregation can be modified externally, it will be difficult to ensure the consistency of data within the aggregation. Therefore, we need to have a unified entry point for data input modification to ensure that data modification within the aggregation uniformly conforms to the business rules in the aggregation, hence the concept of aggregation root. An aggregate root is essentially an entity with a unique identity and an independent life cycle. But it is a special entity that coordinates entities and value objects to complete business logic, just like the head of a department. An aggregate has only one aggregate root, which organizes and coordinates entities and value objects in a reference-dependent manner within the aggregate, and coordinates the aggregate root and the aggregate root through a unique ID.

Strategic design

The four words of strategic design sound a little lofty feeling, feeling far 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. This guiding content can be called strategy. In THE DDD field, strategic design is mainly based on business perspective, dividing business domain boundaries, establishing bounded context based on common language and business context semantic boundaries, and realizing the construction of business domain model. This allows the bounded context to be used as a boundary for microservice decomposition and design. Only with a well-defined domain model and context can we design a well-defined microservice. Therefore, the most important aspects in the strategic design phase are 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 the business expectation. In carries on the strategic design process, the need for comprehensive business, the business area segmentation in the first place, differentiate the context of business boundaries, and establish the corresponding limit above the domain model, context boundary and the domain model can be based on micro service split split design input, design of micro service landing split. In business, the corresponding domain model is very important. So what approach can we take to build a highly cohesive, low-coupling domain model from a complex business domain? We can build the domain model through business analysis and domain modeling.

Business analysis

1. Event storm

The method of event storm can quickly analyze and decompose the complex business domain, analyze and extract the corresponding domain model. Event storm was proposed in 2013 by organizing domain experts and project team members to brainstorm and sort out all domain events in the business domain as well as participants and inputs of domain events. Participants include domain experts, DDD experts, architects, product managers, project managers, developers, and testers. After the participants are brought together, they brainstorm the current business domain issues. Such as whether a business action or behavior triggers the next business action, what are the inputs and outputs of that action (domain event), who (entity) issues what action (command), and triggers that action.

Let’s take the most familiar e-commerce system for example, there is an important link in e-commerce business is logistics. Therefore, logistics is an important business subdomain of e-commerce business. When the user finishes the order, the picking list corresponding to Chen Cheng is needed in the storage field. According to the goods in the picking list, the system generates the corresponding picking tasks for the warehouse operators in different zones. The operators pick up the goods according to the corresponding picking tasks and put them into the corresponding cargo containers. Finally, all orders of goods will be merged after the completion of picking, check, and finally form packages for the subsequent distribution process. In this process, we will involve entities such as orders, picking orders, picking tasks, users, containers, etc., and the corresponding value object is address information. Field events are picking order generation and picking task generation.

Domain modeling

In my opinion, domain modeling is actually the most important aspect of DDD domain-driven design. Yes, a good domain model means that the business processes are well combed and the business domain is well abstracted. The high cohesion and low coupling domain model can directly determine the quality and level of microservice design.

1. Identify entities and value objects

After the overall business sorting, we can find corresponding entities and value objects in business objects, which will involve which domain objects are designed as non-entities, and which domain objects are designed as value objects. It depends mainly on the actual business characteristics.

2. Build aggregation

After combing through the business, we found all the entities and value objects under the business, and then we built the aggregation. Before building an aggregation, we need to find the root of the aggregation from the entity set. This is like fighting a war to capture the enemy king. After the king is captured, the soldiers who belong to the following will obedientlyobey. So how do we know that an entity is an aggregate root? It depends on whether the entity has a dedicated module for maintenance, whether it has a complete and independent life cycle, and whether it has a global unique ID. Through this several judgment conditions we can easily find the corresponding aggregation root, as shown in the figure below, in operation within the warehouse tasks, including picking orders is an aggregation, satisfy the above several conditions, at the same time can be associated with its business entities such as goods, picking container merge to the picking orders, such as picking polymerization can eventually form.

Partition aggregate to bounded context

First of all, we need to list all the domain events sorted out previously and trigger commands of event flow. In this process, the objects generating business behaviors, namely the entities mentioned above, are extracted. As mentioned above, inventory, containers. In this process, we need to find the corresponding entity and value object, and find the aggregation root in these entities, divide the aggregation root, entity and value object with close business logic relationship together to form the aggregation, and then slide multiple aggregations into the bounded context according to the previously divided boundary context.

Tactical design

Different from the strategic design, tactical design is based on the actual technical perspective. It focuses more on the technical realization of the domain model, and completes the development and implementation of micro-services according to the domain model. In a sense, strategic design is actually the input of tactical design. In tactical design there are code implementations of aggregations, aggregating roots, entities, value objects, domain services, and domain events, by mapping these domain objects into the code to achieve design and system landing. At this stage, we need to tease out the boundaries of microservices and the domain objects within the boundaries and the relationships between them, and we can actually identify the domain models in which code modules and specific locations in the microservice hierarchy. With DDD, the business domain can be subdivided according to certain rules, so that the scope of the problem can be limited to the specified boundary, so that we can build the domain model within this boundary, and then implement the domain model through the code to solve the corresponding business problem. Therefore, in the tactical design stage, we have an important issue to complete, one is the domain object analysis and boundary demarcation of microservices, the other is the structure stratification of microservices.

Object analysis and boundary demarcation in microservice domain

In the strategic design phase, we have built the business domain model, which contains entities, value objects, and aggregate roots. We have actually divided the microservices into aggregations based on some business domains above, so here we need to continue to divide the microservices based on different aggregations and existing bounded contexts. Some microservices contain multiple aggregations, while others have only one.

Microservices are layered

In the traditional engineering code structure, most of the MVC engineering structure is adopted. However, with the advent of the era of micro services, traditional engineering structures can not meet the rapidly changing business needs. In addition, with the implementation of DDD domain driven design, there is a need for further evolution and upgrading of the engineering architecture of microservices.

Eric Evans, in Domain-Driven Design: Solutions to Software Core Complexity, proposes the traditional four-tier structure, but it has its problems. In DDD domain-driven design, the domain layer should be the core layer, but in the traditional four-layer structure, the base layer is at the core, which is a bit of the cart before the horse. 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.

Base layer: Basically, other layers that are not microservices provide the basic general technical support, such as Redis, MQ, and databases, where database persistence can be located. User interface layer: it is responsible for displaying information to users and transforming user request intention. When the front and back ends are separated, it can adapt to different user front ends under the condition that the back-end services remain unchanged. Application layer: It can be understood as the orchestration and composition of services that implement domain objects and multiple aggregates and should not have too much business logic. Domain layer: The domain layer is essentially the core of the microservice, where the 㛑 state changes of domain objects and domain rules are involved. The domain layer consists of entities, value objects, aggregate roots, and domain services. Of course, there are actually other hierarchical structures such as five hierarchical structures, hexagonal hierarchical structures.

conclusion

This paper mainly focuses on the three processes of DDD field driving design landing time, and explains the input and output of strategic design stage and tactical design stage in detail. We hope that we have a direction for how to implement DDD domain-driven design guidance, the following articles will continue to elaborate on DDD specific implementation details and some suggestions.