DDD Domain-Driven Design Thought - Summary of Reading "DDD Practical Course"

This article is a summary of my own thinking after learning Geek Time "DDD Practical Course". The course link is at:

DDD practical course splitting and design of microservices based on DDD

1. Explanation of DDD terms

(1) Domain

After subdividing the business domain, delimit the problems within a certain range. The problems within this range form the domain. The domain is hierarchical, and a domain can be aggregated by multiple 'subdomains'. The types of subdomains can be divided into:

• The core domain determines the sub-domain of the core competitiveness of the company's products
• A subdomain of a function that is used by multiple subdomains at the same time
• The support domain does not contain the functions that determine the core competitiveness of products and companies, nor does it contain subdomains of general functions. It is the support domain, such as systems such as the data dictionary of data codes.

The sub-domain can be further split into sub-sub-domains as needed, for example, the payment sub-domain can be further split into payment and payment sub-sub-domains. After demolition to a certain extent, the domain boundaries of some sub-subdomains may become the boundaries of bounded contexts.

(2) Bounded Context

The bounded context defines the boundary of the domain model, each domain model has its own domain boundary, within the domain boundary is the bounded context. The bounded context restricts a unified common language (in the bounded context, in the event storm process, the language that can simply, clearly and accurately describe business meaning and rules is the language that can reach consensus through team communication), as well as domain objects, etc. Generally speaking, in the microservice architecture, without considering other factors (such as technology heterogeneity, team communication, etc.), microservices can be defined according to the bounded context.

(3) Aggregate, Entity, Value Object, Aggregate Root

Entities and value objects are the basic units of aggregation, which is the basic unit that forms the domain model. In the event storm, we will find entities (Entity) or value object (ValueObject) according to some business operations and behaviors, and then combine closely business related entities and value objects to form aggregates, and then aggregate multiple aggregates according to business semantics Delineate into the same bounded context (Bounded Context) and complete domain modeling within the bounded context.

• Aggregation Aggregation is a combination of entities and value objects that are closely related to business and logic
• Entities are the basic carriers used to describe business operations and behaviors, with unique identifiers.
• A value object entity may aggregate a value object. The value object is equivalent to a data carrier with multiple fields. It depends on the existence of the entity, does not contain business logic, has no unique identifier, and only involves overall replacement and data initialization in the business. There are two ways in database modeling. One way is to design a field as a large field to store the Json of the value object, and the other way is to create a new field by juxtaposing all the fields of the value object with other attribute fields of the entity.
• The aggregate root is also called the root entity. The communication between aggregates is managed by the aggregate root. It accepts external tasks and requests in the form of an aggregate root ID. That is to say, if an aggregate needs to access other aggregate entities, it is necessary to First access the aggregate root, and then navigate to the aggregate internal entity, external objects cannot directly access the aggregate internal entity.

(4) Domain events

DDD advocates that the business collaboration generated between aggregations is done by using domain events. Domain events are to abstract the action of upstream aggregation processing through events, encapsulate the data required to complete downstream aggregation, and use message queue middleware (cross-micro service) or the message bus framework in the local application (the same microservice across aggregations) to complete the decoupling of services between aggregations.

2. DDD layered architecture and code layering in actual combat

(1) Four-tier architecture

• The user interface layer is used to provide a unified external interface. The same application service may be used for different terminals, and the input and output parameters are not the same. Therefore, a user interface layer is added upstream to process input and output parameters in different formats, providing Reuse of application service layer.

• The application layer orchestrates the interfaces provided by various domain services or other microservices, and cooperates to complete business operations. The granularity of application services is relatively coarse, and it is necessary to pay attention to reusability. The application service can also perform security authentication, permission verification, transaction control, sending or subscribing domain events, etc. In addition, the application layer code is relatively thin and does not contain business rules or logic. It mainly controls the direction of business processes, and the logic part is delegated to the domain layer.

• The domain layer mainly includes entity classes, value object classes, event classes, and domain services. Domain services are called by the application layer to implement business rules and logic, but for some actions only related to a single entity itself, this part of the logic is implemented by the entity class itself.

• Basic layer The basic layer runs through all layers, and its role is to provide common technologies and basic services for other layers, including third-party tools, drivers, message middleware, gateways, files, caches, and databases.

(2) Code layered reference

1. api (convenient for deploy, for synchronous call)

mainly includes:

• dto package, that is, the data transfer object, that is, the data transfer field encapsulation between internal interfaces. Including requestDTO and responseDTO two parts.
• The api interface, the api interface, is inherited by the feignClient interface.

2. Interfaces (user interface layer)

Secondary directories include:

• Assembler realizes the mutual conversion and data exchange between DTO and domain objects. Generally speaking, Assembler and DTO always appear together.
• Facade provides a coarse-grained calling interface that delegates user requests to one or more application services for processing.
• Encapsulation of data transfer between dto interfaces

3. Application (application layer)

The secondary directories are:

• Service (application service): Encapsulate, orchestrate and combine multiple domain services or other microservice application services to provide coarse-grained services to the outside world. All application services can be placed in one application service class, or an application service can be designed as an application service class to prevent the application service class code from being too large.

4. Domain (domain layer)

Consists of one or more aggregation packages that jointly implement the core business logic of the domain model. Directories inside the aggregation package:

• entity (entity) stores the aggregate root, entity, value object and factory mode (processing DO to PO initialization, DO to PO initialization, means that when the aggregate root is created, all dependent objects in the aggregate will be created at the same time, the All dependent DO objects are converted to PO objects at one time) related code.
• Event (event) Stores event entities and business logic codes related to event activities. It is divided into publish and subscribe directories. Publish stores event publishing related codes, and listener stores event subscription related codes.
• service (domain service) stores the domain service code. A domain service is a piece of business logic composed of multiple entities
• The repository implementation should belong to the basic layer code, but the evolution of the microservice architecture will involve the splitting of the aggregation, so the repository layer is placed here to facilitate the overall migration with the aggregation, including Facade, mapper, and persistence packages, facade is the interface defined to provide services for other layers uniformly, mapper is the mapper interface that needs to be implemented in each framework, persistence is used for the adaptation between PO and query results and query conditions.

5. Infrastructure (base layer)

Secondary directories include:

• config mainly stores configuration related code.
• util mainly stores basic codes such as platforms, development frameworks, messages, databases, caches, files, buses, gateways, third-party libraries, and general algorithms
• client stores feignClient.

3. China-Taiwan Construction and DDD

(1) What is Zhongtai

My superficial understanding of Zhongtai is that Zhongtai is first and foremost a basic conceptual framework. There is no very fixed norm. The core idea is to build small basic services and connect them to jointly support upstream businesses. The biggest benefit is ability. reuse.

(2) Use DDD idea to complete the modeling of middle and Taiwan

First of all, if you use DDD to understand the middle-end architecture, the corresponding relationship can be as shown in the figure:

We have completed the DDD domain modeling, and also completed the middle-end modeling, so how to do it specifically? There are two strategies:

• The top-down strategy is to sort out the fields step by step from the top to the bottom, and finally subdivide them into fields to delineate the boundary between the middle and the platform, which is suitable for the situation of knockdown and reconstruction, or new development.

• The bottom-up strategy is to use event storms (which will be described later) to sort out the aggregations of the original systems, divide the boundaries, and form domain models (corresponding to the domain model in the figure above, one domain model corresponds to a middle-office service, consisting of Multiple aggregations), then classify the combed domain models and align the business domains (corresponding to the subdomains in the above figure, which are more abstract than the domain model, such as user authentication and permissions belong to the user business domain, and the business domain is divided into The meaning is to divide different middle-end products, and the human investment of different products may be different), and then analyze the differences and common points of the domain models in the same business domain (the granularity is controlled in the aggregation, try not to divide it within the aggregation) , Precipitate the general functions, redefine the bounded context, divide the domain model, and then classify it according to the domain model (universal middle platform, core middle platform), and then after this reconstruction, the aggregation in the original system will be merged. , the migration of that migration.

Fourth, event storm practice - the key to building a domain model

(1) The core of the event storm

With the product vision as the core, analyze business scenarios, focus on domain objects such as events, commands, and entities in business scenarios, find entities, aggregate roots, divide aggregations, build bounded contexts, and split them into microservices.

(2) Preparations for event storms

1. Participants in the event storm

Can include:

• Domain experts, i.e. subject matter experts with deep insights into the business or problem domain,
• DDD expert
• architect
• product manager
• project manager
• Developer
• testers etc.

2. Prepare materials

Sticky notes and fountain pens for "painting the wall", ie sticking sticky notes of different colors on the wall

3. Venue

Long enough walls and enough space.

(3) The process of event storm

1. Sort out the product vision

With the participation of domain experts, business demanders, product managers, project managers and development managers, the purpose is to design the top-level value of the product, so that the product target users, core values, differentiated competition points and other information can be agreed, so as to avoid the product from deviating from the direction. For example, it is organized into the following vision wall, taking the design of a user mid-stage product as an example, everyone expresses their opinions on each point and sticks them on the wall:

2. Business scenario analysis

Involved by domain experts, product managers, requirements analysts, architects, project managers, development managers and test managers, from the perspective of users, based on business processes or user journeys, using use case and scenario analysis to explore typical scenarios in the domain, Identify domain objects such as domain events, entities, and commands to support domain modeling. Taking the design of the user center as an example, the user center has three typical business scenarios: the first is system and position settings, setting menu permissions for positions in the system; the second is user permissions configuration, which creates accounts and positions for users. Password, set the user position; the third is the user login system and permission verification, generate user login and operation logs. Search for key domain events in the user's business process step by step, such as job created, user created and other events. Find out what behaviors will cause these domain events. These behaviors may be generated by a combination of one or several commands. For example, when creating a user, the first command is to obtain user information from the company's HR system, and the second command is Create a user in the user center based on HR's employee information. After the user is created, the domain event created by the user will be generated. Of course, this domain event may trigger the next action, such as publishing to the mail system to notify the user that it has been created, but it may also end here. Arrange as shown:

3. Domain Modeling

With the participation of domain experts, product managers, requirements analysts, architects, project managers, development managers and test managers, according to the relationship between the domain objects generated in the scenario analysis process, such as commands, events, etc., find out the entities that generate commands, Analyze the dependencies between entities to form aggregates, define bounded contexts for aggregates, and establish domain models and dependencies between models.

(1) The first step - find the entity

Extract the entities that generate these behaviors from the commands and events obtained above, as shown in the figure, sort out the commands and events analyzed above to get the corresponding entities, which are represented by green stickers:

(2) The second step - find the aggregate root and divide the aggregate

According to the management properties of the aggregate root, find the aggregate root in the preceding entities, and then combine the aggregate root and its associated entities and value objects into aggregates according to business dependencies and business cohesion principles. For example, the previous system and menu entities can be combined into a "system function" aggregation. According to this method, the user center has six aggregations of system function, position, user information, user log, account and authentication ticket. .

(3) Delineate bounded contexts and classify aggregations

My understanding is that the previous aggregation is further abstracted and classified according to the business in order to divide the microservices. As shown in the figure, the aggregations obtained earlier are classified into three domain models:

in addition:

Since there are too many domain objects generated in the process of domain modeling, we can use the table to record, as shown in the figure:

4. Divide microservices

In theory, a domain model can be a microservice, but it is not absolute. There are also other factors that need to be considered, such as technological heterogeneity. For example, the amount of user log data is huge, so large that it needs to use big data technology to achieve, then user information aggregation and User log aggregation will have technical heterogeneity. These two aggregations are not suitable to be placed in a microservice. In addition, it is necessary to consider such as the separation of sensitive and stable business, non-functional requirements (such as elastic scaling requirements, security requirements, etc.), team organization and communication efficiency, software package size, and technical heterogeneity (the technical environment used different) and other non-business factors.

{{o.name}}

{{m.name}}