DDD Domain Driven Design

Early Design Flowchart
Object-Oriented System Design Process

DDD falls to the database

Domain Object Persistence Thought
- Store temporarily unused objects from memory to disk persistently. When using this domain object again, look up this record in the database according to the key value, and then restore it to a domain object, and the application can continue to use it
The database design of DDD has become the process of transforming the domain model into database design with the domain model as the core.

Traditional 4-way relationship direct conversion

Three Design Schemes for Inheritance Relationships

- Advantages: Simple, all the data of the entire inheritance relationship is stored in this table
- Disadvantage: cause "table sparse"

Convert to NoSQL data

Relational databases follow the third paradigm, which enables the database to greatly reduce redundancy, but database queries require frequent operations join, and the performance is low in high-concurrency scenarios
In the NoSQL database, jointhe query is written into the database table before the join operation, and directly written into a form for distributed storage. This table is called a "wide table".

Domain Model Guides Program Design

Service

It identifies operations and behaviors outside of domain objects, receiving user requests and performing certain operations
When the user performs an operation in the system interface, a request will be sent to the system, and the "service" will receive these requests from the user, and then execute the corresponding method according to the requirement. After all operations are completed, the data in the entity or value object Persist to the database

Entity

Differentiate each individual domain object in the real world through a unique identification field
Mutability is a characteristic of entities

value object

Represents those immutable and essential things in the real world
Immutability is the essence of value objects

Anemia model and hyperemia model

Anemia model
- There are many POJO objects, except for a bunch of get/set methods, there is hardly any business logic
- Simpler and easier than the hyperemia model
hyperemia model
- Convert the original appearance in the domain model directly to the domain design in the program, and various service operations are not implemented in the service, but in the domain object
- The original appearance of the domain model is maintained, and the code modification is relatively straightforward
- Object encapsulation is maintained, changed in
Anemia model is simpler and easier to implement than congestion model
Hyperemia Models Require Greater Design and Collaboration Capabilities
- The hyperemia model requires developers to have stronger OOA/D capabilities, business analysis, business modeling and design capabilities
- Hyperemia models require strong teamwork skills
- All business processes of the anemia model are handed over to the Service to complete
Anemia model is easier to deal with complex business scenarios
- Using the anemia model, divide complex business processing scenarios into multiple independent steps, and then assign these independent steps to multiple services to execute in series
Put the required business logic into the domain object and design according to the hyperemia model
- Situations similar to inheritance and polymorphism appear in the domain model
- Convert some types or codes in the process of software design
- Better representation of relationships between domain objects in software design
- "Aggregation", representing whole and part transactions in the real world
In addition to other business logic into the Service , designed according to the anemia model

Aggregates, warehouses and factories

aggregated design

Aggregation expresses the relationship between whole and part in the real world

When creating an order: create the order details in the order
When saving the order: save the order table and order details at the same time, and put them in the same transaction
When querying orders: query the order table and order details table at the same time, and assemble them into an order object

When the whole does not exist, the parts become meaningless
The part is encapsulated in the whole, through the whole to operate the part, the whole is the only entrance for external access: aggregate root
Additions , deletions, and modifications can adopt domain-driven design

Aggregation implementation

Warehouse (Repository)
- The system puts domain objects in the warehouse, and fetches them from the warehouse by ID when needed;
- Get domain object by ID
  - The warehouse first searches the cache through the ID, and returns directly if found
  - Not found, notify the factory, the factory calls DAO to query the database, and then assembles it into a domain object and returns it to the warehouse
  - cache object, return object
- Difference from Data Access Layer (DAO)
  - When the data is saved, DAO is responsible for saving, but what is saved is a single table
  - When data is queried, through DAO query, the query is a single table

DDD's factory
The system wants to load an order by ID
- The order warehouse hands the task to the order factory, and the order factory calls the order DAO, order details DAO and user DAO to query
- Set the order details object and user object to the "order details" and "user" attributes of the order object respectively
- The order factory returns the assembled order object to the order warehouse
Through the warehouse and factory, the original DAO is encapsulated in operations such as saving, loading, and querying, and operations such as aggregation and assembly are added to encapsulate these operations, shielding the upper-level program

upper and lower limits

Divide the entire system into many relatively independent business scenarios, and conduct domain analysis and modeling in each business scenario. Such business scenarios are called **"problem sub-domains"**, or "sub-domains" for short.

Domain-driven core design ideas ——restore the analysis and design of software to the real world. The business and problems in the real world are called "problem domains", and business rules and knowledge are called "business domain knowledge".

Bounded context : domain-driven design of a complex system, domain modeling is centered on sub-domains, and domain model designs are drawn one by one

Context Map : Interrelationships between Bounded Contexts

High cohesion within bounded contexts
- Every implemented function within a bounded context is code for the same reason that the software changes
Low coupling between bounded contexts
- When the bounded context calls each other through the context map, it calls through the interface

microservice

Microservice Best Practices DDD

The core problem of microservice design is the splitting of microservices . It is necessary to pay attention to small and specialized design, low coupling and high cohesion
Domain-driven design solves the problem of how to split microservices and realize high cohesion and single responsibility of microservices

The best practice for microservices is DDD

Starting from DDD, requirements analysis, domain modeling, and gradually establish multiple problem sub-domains
Implement problem subdomains into bounded contexts, and the associations between them form a context map
Each sub-domain is implemented into the design of anemia model or hyperemia model in microservices, so as to form an interface between microservices according to the context map

Microservice Design Process

Unified Language Modeling (Solving Requirements Analysis Dilemma)
- Understand business, learn from customers, learn business terminology
event storm meeting
- Under the guidance of the product manager, start to sort out what domain events are in the current business with business experts
  - Domain events: operations that have occurred and need to be saved
  - Add, delete, modify, query does not use DDD, use other requirements analysis
- For each domain event, conduct business analysis around it, add various commands and events, and then consider related resources, external systems and time
- Identify aggregates and their aggregate roots that may be involved in the model

Microservice landing

clean architecture

In the process of implementing DDD, the technology center should be able to encapsulate the design of those cumbersome aggregation operations warehouses and factories, as well as various related technologies

Middle platform

The common components formed by stripping the individuality and extracting the commonality of the foreground and background codes that can be reused in the previous business system.

Business middle platform: make abstract business components into microservices that can be used by all business systems
Technology middle platform: Encapsulate the technical framework to be adopted by each business system, and design a unified API
Data center: organize the data of various business systems, and establish a platform for data storage and calculation

Big front end + technology middle platform

Reduce the workload of business development, increase the speed of development, and lower the technical threshold
Command and Query Responsibility Separation Pattern CQRS
- Command (addition, deletion, and modification operations); software design using domain-driven design ideas
- Query operation; use the transaction script mode, that is, query directly through SQL statements

Architecture design of additions, deletions and modifications

Single Controller Design
- If the method being called has a value object, the value object must be placed as the first parameter of the method
- If the method to be called has both a value object and other parameters, the properties in the value object and other parameters are placed in the Json object
- In actual projects, permission verification needs to be performed before the Controller to standardize the methods that can be called by the front end; use a service gateway or filter for verification
- Controller process design
  1. Obtain Service from Spring according to the front-end parameter bean
  2. According to the front-end parameter method, get the calling method through reflection
  3. Get the first parameter of the calling method as a value object via reflection
  4. Obtain all properties of the value object according to reflection, obtain the value of the corresponding property from the front-end JSON, and write the value object
  5. Obtain other parameters according to the front-end JSON
  6. Use reflection to call the method method in the Service with the value object and other parameters
Single DAO Design
- There can be many attribute variables in the value object, but only the final persistent attribute variables need to be configured
- Each Service is uniformly injected into BasicDao in Spring
  - If you use the function support of DDD, inject the general warehouse Repository
  - If using Redis cache, inject RepositoryWithCache
- Design of DAOs
  1. Single DAO calls VObjFactory.getObj(class) to obtain configuration information vObj
  2. Obtain the corresponding table name according to vObj.getTable()
  3. for(Property prop: vObj.getPreperties()){
    - Obtain the field corresponding to the value object through prop.getColumn()
    - Use reflection to get all properties and their corresponding values from the value object
    - Form the SQL statement through the above parameters
    }
  4. Execute database operations through SQL statements
Development based on this framework, including Spring configuration, MyBatis configuration, and vObj configuration suggestions are all in the form of XML files instead of annotations; easy to transplant

Architecture Design of Query Function

Technical middle platform supporting DDD

Traditional DDD architecture

The design of DDD's warehouse and factory is between the business domain layer and the infrastructure layer (the interface is in the business domain layer, and the implementation is in the infrastructure layer)

Generic Warehouse vs. Generic Factory Design

When loading or querying an order, it is necessary to query the order table, fill in the order details related to the order, customer information, product information and assemble it into an object
When saving an order, save not only the order table but also the order details table, and put them in the same transaction
The decorator pattern is extended on the basis of the original function

Middle…(img-ZI9ldbVe-1678023713068)]

[External link image transfer...(img-nAPcOSTD-1678023713069)]

Generic Warehouse vs. Generic Factory Design

[External link image transfer...(img-PYvF4Kaa-1678023713070)]

When loading or querying an order, it is necessary to query the order table, fill in the order details related to the order, customer information, product information and assemble it into an object
When saving an order, save not only the order table but also the order details table, and put them in the same transaction
The decorator pattern is extended on the basis of the original function
[External link image transfer...(img-RMuT1ZZX-1678023713070)]