当前位置：网站首页>Domain Driven practice summary (basic theory summary and analysis + Architecture Analysis and code design + specific application design analysis V) [easy to understand]

Domain-driven design DDD It's a design idea , It can guide both business modeling and microservice design in midfield ( The essence of midfield is business model , Microservice is the system implementation of business model ), Domain Driven Design emphasizes the integration of domain model and microservice design , First there's the domain model, then there's the microservice , Instead of talking about microservice design away from the domain model .

The root cause of micro service splitting dilemma : I don't know where the boundary of business or micro service is .

DDD The core idea : Define domain model through domain driven design method , To determine the business and application boundaries , Ensure consistency between business model and code model .

For the summary of domain driven design learning, I mainly write three blogs , It mainly includes three parts : Basic theory summary and analysis 、 Architecture analysis and code design 、 Specific application design analysis , The main reference material is the European Innovation architect of geek time 《DDD》 actual combat , Other reference books are in the reference books at the bottom of the article .

The main conclusion of this time is DDD Specific application design analysis ：

One 、 The basic background of the application project

The goal of the project is to achieve online leave and attendance management . The function is described as follows ：

Please fill in the leave form and submit it for approval , According to the identity of the person asking for leave 、 Check the leave type and leave days , Submit it to the superior level by level according to the approval rules , If it is approved step by step, the approval will be completed , Otherwise, the application will be rejected and returned to the applicant .
According to attendance rules , After writing off the leave data , Check the attendance data , Output attendance statistics .

remarks ： I wanted to build a big video business system by myself , But time is too tight , For the time being, I will summarize and analyze the cases provided by European Innovation architects , Later, I will give a video system report .

Two 、 Domain Driven strategic design phase for projects

Strategic design The method used is event storm , Include ： Product vision 、 Scene analysis 、 Domain modeling and microservice splitting And so on .

Strategy design is based on user journey analysis , Find domain objects and aggregate roots , Clustering entities and value objects to form aggregation , Delimit context , The process of building a domain model .

Strategic design stage It is suggested that participants ： Domain expert 、 Business demand side 、 The product manager 、 Architects 、 project manager 、 Development manager and Test Manager .

（ One ） Event storm defines product vision

Product vision is the top value design of products , For product target users 、 The core value of 、 Differentiation, competition point, etc , Avoid product deviation .

Event storm , All participants focused on each point , Write your opinion on the sticker , Stick it on the whiteboard .

The event storm moderator will comment on each sticker , Convergence and unification of divergent opinions are discussed , Form the following product vision map . Actually , That is to say, let everyone determine the general direction of unification and unify the language , What the hell are we doing , What is the purpose and significance of the basic issues .

Product vision analysis is very important for the start-up system , It's valuable to unify team building goals and establish a common language .

For this project , The final product vision map is arranged into a paragraph, which is ：

In order to satisfy the internal and external personnel , Their online leave 、 Automatic attendance statistics and external personnel management needs , We build this online leave attendance system , It's an online leave platform , Automatic attendance statistics . It can support both internal and external network leave , At the same time, manage internal and external staff leave and regular attendance analysis , Not like HR System , Only manage internal people , And it can only be used in Intranet . Our products can be used both inside and outside the Internet , It can realize no difference management between internal and external personnel .

The purpose and significance of achieving ：

Through product vision analysis , The project team unified the system name —— Online leave attendance system , Clear project objectives and key functions , Competing products （HR） The key differences and their own advantages and core competitiveness, etc .

（ Two ） Business scenario analysis of event storm

Scene analysis is From the user's perspective , Explore typical scenarios in the business domain , Classification of scenarios that need to be supported in the output field 、 Use case operations and dependencies between different subdomains , To support domain modeling .

Project team members use event storm to analyze the user journey of leave and attendance .

According to the journey and scene of different characters , Sort out all operations from front-end operations to back-end business logic as comprehensively as possible 、 command 、 Domain events and external dependencies .

Take leave and people scenario as an example ————

Scene analysis one ： Ask for leave user ： Please dummy

The person asking for leave logs into the system ： Get permission information and permission data from permission microservice , Complete login authentication .
Create a leave form ： Open the leave page , Choose leave type and start time , Enter leave information . Save and create a leave form , Submit for leave approval .
Modify the leave form ： Check the leave form , Open the leave page , Modify the leave form , Submit for leave approval .
Submit for approval ： Get approval rules , According to the approval rules , Get the approval person from the person organization relationship , Assign the approval person to the leave form .

Scene analysis 2 ： The examination and approval user ： Approved by

The examiner logs into the system ： Get the information of the examiner and permission data from the permission microservice , Complete login authentication .
Get a leave form ： Obtain the application form under the name of the examiner , Choose leave form .
The examination and approval ： Fill in the approval comments .
Level by level approval ： If it still needs the approval of the superior , According to the approval rules , Get the approval person from the person organization relationship , Assign the approval person to the leave form . Repeat above 4 Step . Finally, the examiner completes the examination and approval .

remarks ： After approval , Generate the domain event that the leave approval has passed . There are two further business operations ： Send the notice that leave approval has passed , Please inform the email system that ; Send leave data to attendance for verification .

Scene analysis three ： People organization relationship Detailed analysis process and attendance scene analysis will not be described

（ 3、 ... and ） Event storm for domain modeling

Domain modeling is based on the analysis of business and problem domains , Build a domain model .

Up, the design of microservice boundary is guided by bounding context , Down through aggregation to guide entity object design .

Domain modeling is a convergent process , three ：

First step ： Find domain objects such as domain entities and value objects

According to the scene analysis , Analyze and identify the entities and value objects that initiate or generate these commands or domain events , Aggregate commands and events related to entities or value objects into entities .

（ Pay attention to nouns and verbs in expressions , Nouns are often entities 、 Value object, etc , Verbs often correspond to the actions related to commands ）

The second step ： Find the aggregate root , According to the entity 、 The dependency between value object and aggregate root , Build aggregations

Before defining aggregation , First find the aggregate root .

From the entity above , We can find out “ Please fake the bill ” and “ personnel ” Two aggregate roots . Then find out the entities and value objects that are closely related to the aggregation root . We found that approval opinions 、 Approval rules are closely related to leave forms , Organizational relationships are closely related to people .

After finding out the relationship between these entities , We found that there were also Credit card details 、 Attendance details and Statistics , These entities have no aggregate roots . This is a situation that you often encounter in domain modeling , For this kind of scene, we need to deal with it in special circumstances ：

Credit card details 、 Attendance details and attendance statistics , They are independent of each other , We can't find the aggregate root , It's not a rich domain model , But they work together to complete the attendance business logic , It has high business cohesion .
We connect these business entities closely , Put it in an attendance aggregation .
In the design of micro Services , We still use DDD The design and analysis method of the system . Since there is no aggregation root to manage the entities within the aggregation , We can manage entities in a traditional way .

Through the analysis of , We set up a system to ask for leave 、 Personnel organization relationship and attendance three aggregation . Among them, there is a form for asking for leave 、 Approval opinion entity and approval rule equivalent object . The aggregation of personnel organization relationship includes such entities as personnel and organization relationship . Attendance aggregation has card details 、 Attendance details, attendance statistics and other entities .

The third step ： According to business and semantic boundaries and other factors , Define the bounding context

Due to the aggregation of personnel organization relationship and leave aggregation , Work together to complete the business function of asking for leave , Both are in the context of asking for leave .

Attendance aggregation constitutes the context of attendance statistics .

Therefore, we divide the business into leave and attendance statistics , Establish two domain models of leave and attendance .

（ Four ） Event storm splits micro Services

In theory, a bounded context can be designed as a micro service , But a variety of external factors need to be taken into account , such as ： Single responsibility 、 Separation of sensitive and steady state services 、 Nonfunctional requirements （ Such as elastic expansion 、 Release frequency and security requirements ）、 Package size 、 Team communication efficiency and technology heterogeneity and other non business elements .

In this project , When we divide micro services, we mainly consider the principle of single responsibility .

Therefore, according to the clearance context, it can be divided into two micro services, leave and attendance . Among them, the micro service for asking for leave includes two aggregations: personnel organization relationship and asking for leave , Attendance micro service includes attendance aggregation .

3、 ... and 、 A domain driven tactical design phase for the project

The tactical design is The process of microservice design based on domain model . This stage mainly combs the domain objects in the micro service , Sort out the relationship between domain objects , Determine where they are in the code model and hierarchical architecture , Establish the mapping relationship between domain model and microservice model , And the dependencies between services .

Tactical design stage It is suggested that participants ： Domain expert 、 The product manager 、 Architects 、 project manager 、 Development Manager, test manager, etc . Tactical design includes the following stages ：

（ One ） Analysis of micro service domain objects

Based on the storm of events , We further refine the domain objects and their relationships , Supplement the business and technical details that may be missed by the event storm ：

We analyze what services should be available in microservices ？
Layering of services ？
Which services are composed and choreographed by application services ？
What entities and entity methods does domain service include ？
Which entity is the aggregate root ？
What are the properties and methods of an entity ？
Which objects should be designed as value objects, etc .

1. Identification and design of specific services

The command of event storm is external operation and business behavior , It is also the ability of micro service to provide external services . It often corresponds to the application service or domain service of micro service . We You can use commands as a starting point for service identification and Design .

The specific steps are as follows ：

Design application services according to commands , Determine the function of the application service , Service collection , Combination and arrangement . The services in the service collection include domain services or application services of other micro services .
Design domain services according to the functional requirements of application services , Define domain services . Here we need to pay attention to ： Application services may be composed of multiple aggregated domain services .
According to the function of domain service , Identify entities and functions within domain services .
Basic properties and methods of design entities .
Consider asynchronous processing of domain events .

Take the action of submitting for approval as an example , To illustrate the identification and design of services . The general process of submitting for approval is ：

According to the type and duration of leave , Query leave approval rules , Get the role of the next examiner .
Query the next examiner from the personnel organization relationship according to the approval role .
Assign the approval person to the leave form , And save the approval rules to the leave form .

Through analysis , We need to design the following services and methods in the application layer and domain layer .

application layer ： Submit approval application service .
Domain layer ： Domain services have query approval rules 、 Modify the leave process information service and query the approval person service according to the approval rules , They are respectively located in leave and personnel organization relationship aggregation . Leave form entity has the method to modify leave process information , The value object of approval rule has the method of querying approval rule . The personnel entity has the method to query the approval person according to the approval rules . The following figure shows the services we analyzed and the dependencies between them .

2. Object analysis in aggregation

stay Leave application forms are being aggregated , The aggregate root is the leave form .

After multi-level review of leave application form , There will be multiple approval opinions , For the convenience of inquiry , We can design approval opinions as entities .
After the approval of leave , There will be domain events that have passed the leave approval , So there will also be leave event entities .

There are several ways to ask for leave Entity ： Approval comments （ Record approval by 、 Approval status and opinions ） And leave event entity .

Let's analyze the value object of leave form aggregation .

Please note that the dummy and the next examiner data are from the personnel entity in the personnel organization relationship aggregation , Can be designed as a value object .
The type of people 、 Leave type and approval status are enumeration value types , Can be designed as a value object .
After determining the leave approval rules , The approval rule can also be used as the value object of the leave form .

Leave form aggregation will include the following The value object ： Please dummy 、 The type of people 、 Leave type 、 The next person to approve 、 Approval status and approval rules .

—————————————————————————————————————————————————–

Aggregation of personnel organizational relationships in , We can build organizational relationships between people , Find the superior approval leader through the organization relationship type .

Its aggregate root is people , Entities have organized relationships （ Including the type of organizational relationship and the superior approval leader ）, Among them, the type of organizational relationship （ Such as the project manager 、 Director of the 、 General manager, etc ） Value object . The leader of superior examination and approval comes from the root of personnel aggregation , Can be designed as a value object . The aggregation of people organization relationships will include the following The value object ： Types of organizational relationships 、 Higher level approval leaders .

3. The list of objects in the microservice

After determining the attributes of each domain object , We can design the code objects of domain objects in the code model （ Include the package name of the code object 、 Class name and method name ）, The mapping relationship between domain object and code object is established .

According to this mapping relationship , Relevant personnel can quickly locate the code location where the business logic is located .

（ Two ） Design microservice code structure

according to DDD The code model and the package of each domain object 、 Classes and methods , You can define the code structure of the leave micro service , Design code objects .

1. Application layer code structure

The application layer includes ： Application service 、DTO And event release related code .

stay LeaveApplicationService Implement application services related to aggregation in class , stay LoginApplicationService Application services encapsulating external micro service authentication and permissions .

( As a reminder ： If the application service logic is complex , An application service can build a class , In this way, the code of a class can be avoided to be too large , Not conducive to maintenance .)

2. Domain layer code structure

The domain layer includes one or more aggregated entity classes 、 Event entity class 、 Field services and factories 、 Storage related codes .

An aggregation corresponds to an aggregation code directory , There is complete code isolation between aggregations , The aggregation is coordinated through the application layer .

Leave micro service domain layer includes leave and personnel aggregation . The personnel and leave codes are put in the code package of the directory structure where the aggregation is located .

If as the business grows , Personnel related functions need to be separated from the leave micro service , We just need to modify the personnel aggregation code package a little , Independent deployment , It can be quickly published as personnel micro service .

（ 3、 ... and ） Follow up work ： Detailed design + Code development and testing

1. Detailed design

After completing the domain model and microservice design , We also need to design micro services in detail .

The main design contents are as follows ： Entity properties 、 Database tables and fields 、 Entity and database table mapping 、 Service parameter specification and function implementation .

2. Code development and testing

Developers only need to follow the detailed design documents and functional requirements , Find the code location corresponding to the business function , Just complete the code development .

After code development , Developers write unit test cases , Complete the service test based on the simulation dependency object .

Four 、 Specific code reference

This summary is based on the geek time course 《DDD actual combat 》 European Innovation architect's example project , Related code can be cloned ：

https://github.com/ouchuangxin/leave-sample.git

It will be supplemented in the later stage , And the project analysis of video system , Post in the follow-up blog .

Reference books 、 Literature and materials

1. Geek time course 《DDD actual combat 》, Ou Chuang Xin ,2019.

2. Zheng Tianmin . Microservice design principles and Architecture . Beijing ： People's post and Telecommunications Press ,2018.

Publisher ： Full stack programmer stack length , Reprint please indicate the source ：https://javaforall.cn/125709.html Link to the original text ：https://javaforall.cn

原网站

版权声明
本文为[Full stack programmer webmaster]所创，转载请带上原文链接，感谢
https://yzsam.com/2022/204/202207221359304035.html