DDD Domain Driven Design Notes

One . Preface

       Contact DDD It's been a while , Including our own projects is to follow DDD Designed directory structure and code structure , Unfortunately, there is no relevant boss in the team who can train this . Today, I have nothing to do but tidy up my DDD Take notes .

notes ： After all, it's sorting out your notes , Some contents do not record reference links , Excuse me . And only limited to their own understanding , There are some mistakes , Welcome the boss to correct ~

Two . Text

1. What is? DDD

Domain driven design is divided into two stages ：

（1） As a domain expert 、 The designer 、 A common language that developers can understand as a tool for communicating with each other , Discover domain concepts in the process of communication , Then we design these concepts into a domain model ;
（2） Driving software design by domain model , Code to implement the domain model ;.

DDD Advocate that the engineering team must work with subject matter experts (SME) conversation , They are experts in the field . And the reason for that is SME Knowledge of the field , This knowledge should be reflected in the software . think about it , If I want to be a stock trading platform , As an engineer , Do I know enough about this field to make a good stock trading platform ？ If I could talk to Warren · Buffett talks about this field , This platform may be much better .

2.DDD and MVC The difference between

（1）DDD Hierarchical structure of

（2）ddd The architecture and mvc The corresponding relationship of architecture

       Conventional mvc structure , After receiving the demand , We may design first mysql Data sheet for , Then match the fields of the table with the business scenario , It's a kind of From the bottom up Design idea .

       And in the DDD in , After receiving the demand , First, we need to Discuss , Clarify the requirements and corresponding scenarios , Divide the subdomain of requirements and the bounding context , Even entities , Value object, etc . After developers are familiar with the requirements , Start From top to bottom Design code model , Final implementation requirements .

       Look like DDD Compared with the traditional mvc It's going to be a lot of trouble , Yes , It's really troublesome ... But for fast iterations or complex large projects , follow DDD It can make your code more extensible , The design of high cohesion and low coupling can also prevent the production of Shishan , It can be said that the credit will last forever .

Reference link ：mvc and DDD The difference between

3.DDD The overall architecture diagram

Reference resources ： Meituan senior technical specialist ：DDD Practice in the evolution of tourism e-commerce architecture

       This ppt It's about design DDD The specific process of , I suggest you can go and have a look , Very careful . We can know from this picture DDD A design process of , From discussion to refining a specific model , Design various subdomains and bounded contexts, etc .

3、 ... and 、DDD An explanation of the concept of

1、 Strategic design and tactical design

DDD It is mainly divided into two parts , Strategic design and tactical design , The strategic design revolves around the separation of micro services , Tactical design is built around micro services .

The details are as shown in the picture ：

2、 Related concepts of strategic design

(1) field

The field here refers to the business field .
       In the process of continuous division of fields , The domain will be subdivided into different sub domains , Subdomains can be divided into three types according to their importance and functional attributes , They are ： Core domain 、 Common domain and support domain .

Core domain ： The sub domain that determines the core competitiveness of products and companies is the core domain , It is the main factor of business success and the core competitiveness of the company .
Common domain ： There's not much personalized appeal , A common functional subdomain used by multiple subdomains at the same time is a common domain .
Support domain ： There is also a functional subdomain that is required , But it does not include the function of determining the core competitiveness of products and companies , It also does not contain sub domains of general functions , It's the support domain .

(2) Bound context

Reference resources ：DDD（ Domain-driven design ） Series theme ： Bound context

       Disassemble the boundary context into two words ： Bounds and context . The boundary is the boundary of the domain , And context is the semantic environment . In many articles, it is said that the bounded context is our microservice , This statement is also true , But the bounded context can also be a concept in the subdomain .

1） Microservices
       stay DDD Identified at the strategic design stage “ Bound context ”, It will be the main basis for the design and splitting of microservices in the tactical design stage , Theoretically “ Bound context ” The boundary of is the physical deployment boundary of microservices .
2） Within the same service
       In one service , In addition to limiting large areas , There will also be the concept of subdomains . A domain is equivalent to a problem domain , The process of domain splitting into subdomains is the process of big problems splitting into small problems .
Then the boundary between the subdomains , It can also be a bounded context , Ensure aggregation within each sub domain , Semantic uniqueness .

（3） Anticorrosive coating

Anticorrosive coating （ACL）：DDD（Eric Evans） The pattern introduced in , Used to isolate two systems , Allow two systems to integrate without knowing each other's domain knowledge .

1） Anticorrosive coating between services

1、 At the architecture level , By introducing an anti-corrosion layer, the coupling between boundary contexts is effectively isolated ;
2、 The coating can also act as an adapter 、 Mediator 、 appearance （Facade） Wait for the character ;
3、 The anticorrosive coating often belongs to the downstream clearance context , It is used to isolate the possible changes of upstream boundary context ;

2） Anticorrosive coating in the same service

       For example, order service , It may also contain goods , Order , Sub fields such as settlement and payment . In order to maintain the independence of each sub domain , Define anticorrosive coating , Just do a layer of conversion for the calls between various sub domains .

3、 Concepts related to tactical design

（1） Entities and value objects

       Entities generally correspond to business objects , It has business attributes and business behaviors ; The value object is mainly a collection of attributes , Describe the state and characteristics of the entity . But entity and value objects are just individualized objects , Their behavior shows the individual's ability .
give an example ： people , That is, the business type itself

（2） polymerization

       Aggregation is a combination of entities and value objects closely related to business and logic , Aggregation is the basic unit of data modification and persistence , Each aggregation corresponds to a warehouse , Data persistence .

       Aggregation contains entities , The lifecycle of an entity is managed by the aggregation root . Aggregations are referenced by aggregation root Association , If you need to access other aggregated entities , First visit the aggregation root , Then navigate to the entities inside the aggregation .
give an example ： An association , organization , department

（3） Aggregate root

       If you compare polymerization to organization , Then the aggregator is the person in charge of this organization . Aggregate roots are also called root entities , It's not just an entity , Or the manager of aggregation .
Aggregate roots are separated by ID Navigation ,OrderItem Hold... In the library ProductID instead of Product Of reference. When used by ProductID from ProductRepository in load come out . This is in DDD It's called the lost connection model (disconnected model)

（4） Storage

       It is mainly used in conjunction with infrastructure . The infrastructure may be a database , File or memory object . The storage layer is for crud Made a layer of abstraction . For example, decoupling business and mysql The previous strong coupling relationship ,
Call the warehouse to realize persistence or query operation , Don't care about the specific implementation .

Reference resources ：DDD Series articles

Four 、DDD Division in the directory

（1） Subdomain level

├─catalog            //  Commodity directory subdomain 
│  ├─application
│  ├─domain
│  ├─infrastructure
│  └─presentation
├─order              //  Order subfield 
│  ├─application
│  ├─domain
│  ├─infrastructure
│  └─presentation
└─store              //  Business sub domain 
    ├─application
    ├─domain
    ├─infrastructure
    └─presentation

（2） Business module level

├─catalog            //  Commodity directory subdomain 
│  ├─application        //  application layer 
│  │  ├─brand
│  │  ├─category
│  │  ├─collection
│  │  └─product
│  ├─domain             //  Domain layer 
│  │  ├─brand               //  Commodity brand module 
│  │  ├─category            //  Commodity category module 
│  │  ├─collection          //  Commodity collection module 
│  │  └─product             //  Commodity module 
│  ├─infrastructure     //  Infrastructure layer 
│  │  └─persistent          //  Persistence 
│  │      ├─jpa
│  │      ├─mybatis
│  │      └─redis
│  └─presentation       //  The presentation layer 
│      ├─graphql
│      ├─grpc
│      ├─rest
│      ├─view
│      └─websocket
└─order
    ├─application
    │  ├─dispute
    │  ├─review
    │  ├─shipping
    │  └─source
    ├─domain
    │  ├─dispute
    │  ├─review
    │  ├─shipping
    │  └─source
    ├─infrastructure
    └─presentation

end