Microservices and DDD domain-driven design model
What is DDD domain-driven design
The first to introduce domain-driven design is in the book "Domain-driven Design: Complex Software Core Complicated Solutions" published by programmer Eric Evans in 2004. Domain-driven design is the extension and application of domain concepts. And apply it in software development. Its goal is to connect the relevant parts of the software to the evolving model, making it easier to create complex applications.
For DDD implementation cases, please refer to the following article:
“[Practice of Domain Driven Design in Internet Business Development]
https://tech.meituan.com/2017/12/22/ddd-in-practice.html
”
What you need to know about DDD
Anemia model
“Objects in anemia field
Anemic Domain Object (Anemic Domain Object) refers to a domain object that is only used as a data carrier without behavior and action.
”
Simply put, it is an entity with only Getter/Setter methods. Since there are objects in the anemia domain, there are also objects in the congestion domain.
“Congestion domain objects
In addition to Getter/Setter methods, entities also have methods for describing entity behavior and actions
”
Let's take an example, here is an order entity Order.
The above entity does not have a method to describe the entity's behavior, so the entity is an anemia model.
If we need a special way to modify the order for delivery, we can write like this
What does it look like if you write with a hyperemia model?
We have added methods to describe the behavior of the order status buildDeliveryStatus().
The method of order delivery is modified to
Here we directly call order.buildDeliveryStatus()to get the behavior of the shipping status, hiding how the specific behavior is generated.
In fact, according to the usual thinking, the anemia model is fine, but when the business logic becomes complex, the business logic and state will be scattered in a large number of methods, and the original code's intention will gradually become unclear.
“I think that developers who use the congestion model do not need to care about the specific details of the behavior, only need to use this behavior, which conforms to the design principles of object-oriented packaging
”
Aggregate root
Aggregate is a collection of related objects that are accessed by the outside world as a whole. Aggregate Root is the root node of this aggregation.
entity
When an object is distinguished by its identity (rather than attributes), such an object is called an Entity.
Value object
When an object is used to describe a transaction without a unique identifier, it is called a Value Object.
Aggregate root
Why do microservices need DDD domain-driven design
"Microservice Architecture and Design Patterns" wrote in Chapter 2 Service Splitting Strategy that we can split a single service into microservices in the following ways:
“”
Split by business capability
Split by subdomain mode
In this article, we will not discuss what microservices are. If you don't understand the children's shoes of microservices, you can read this book.
In large-scale software development, it is very difficult for all teams in the organization to agree on a single global model and terminology. Some teams in the organization may use the same terminology for different concepts, and some teams may target the same concept. Using different terminology, DDD can avoid these problems by defining multiple domain models, each of which has its own clear scope.
Before dividing services, we first need to create an abstract domain model. Each service has its own domain model. The abstract domain model helps in the service division phase. It defines some words that describe the behavior of the operating system. .
Domain model
The figure above is a schematic diagram of the domain model in the early stage of system development.
Splitting by subdomain mode adopts the idea of DDD domain-driven design. Domain-driven design is a very effective methodology for building complex software. In domain-driven design, the domain model is the core, and domain-driven design has two important concepts: subdomain and bounded context.
A part of the domain is the subdomain, and the boundary of the domain is the bounded context.
Bounded context
As shown in the figure above, the elliptical dashed line indicates the bounded context, and the dashed line encloses the subdomain. Each subdomain maps a domain model.
“The concepts of subdomains and bounded contexts in DDD match well with the services in the microservice architecture. The autonomous team in the microservice architecture is responsible for the development of the concept and each domain model in DDD is developed by an independent team. The concept is consistent.
”
Layered architecture of domain-driven design
The traditional architecture is the three-tier architecture.
“”
Presentation layer (Controller layer): contains the code that implements the user interface or external API
Business logic layer (Service layer): contains business logic
Data persistence layer (Dao layer): realize the logic of interaction with the database
This layered architecture incorrectly represents the dependencies of a well-designed application. Business logic usually defines the interface of the data access method (addition, deletion, modification, and query logic). The data persistence layer defines the Dao class that implements the database interface. This dependency is the opposite of what the layered architecture describes.
Layered architecture in the domain-driven model
Domain stratification
-
User Interface-User interface layer: Controller, restful interface call, or web UI interface, mobile UI interface, third-party services, etc.;
-
Application-application layer: Provides various application functions for the presentation layer externally, and calls the domain layer (domain service) internally. The application layer is more like a strategy to implement a specific scenario or process orchestration. It cooperates with services in multiple fields to realize the isolation of scenarios and businesses;
-
Domain-Domain layer: Responsible for expressing business concepts, business behaviors, business states, and business rules. The domain model is at this layer and is the core of business software. What it provides is a series of atomic services. Providing a rich OPEN API at this layer is a crucial step in achieving componentization;
-
Infrastructure-basic layer: realize the isolation layer of business and technology. Generally include: network communication, database persistence, asynchronous message service, southbound gateway service, etc. When this layer is launched, multiple adapters can be implemented to be compatible with internal, external, and multi-cloud heterogeneous middleware environments.
Thinking about this layering
In an object-oriented program, the user interface, database, and other supporting code are often written directly into the business object. Additional business logic is embedded in the behavior of UI components and database scripts. Some of the reasons for this is that it makes it easy to get things to work quickly.
However, when domain-related code is mixed into other layers, it becomes extremely difficult to read and think about it. On the surface, it looks like a modification of the UI, but it has become a modification of the business logic. Changes to business rules may require careful tracking of user interface layer code, database code, and other program elements. The implementations are glued together, and model-driven objects become no longer feasible. It is also difficult to use automated testing. For the technology and logic involved in each activity, the program must be kept simple, otherwise it will become difficult to understand.
Therefore, we need to correctly divide a complex application into layers, develop the cohesive design in each layer, concentrate the code related to the domain model into its own layer, and separate it from the user interface, application and infrastructure code Isolate.
If the code is not clearly separated into a certain layer, the entire application layer sequence code will appear messy and become difficult to manage. A simple modification to the code in one place will cause unknown hidden dangers to the code in other places. The domain layer should be concerned about the problems of the domain layer, and it should not involve activities of other layers.
Specific domain model layered code actual combat
The package name in the project can refer to the figure above.
Let's take a look at how my project references the DDD domain-driven design model:
First, I created several packages: application、controller、domain、infrastructure. The controllerpackage here is actually the User interface layer.
application
applicationIt mainly writes some business aspects service.
domain
domainThe main part is to write some methods of dealing with the database (basic additions, deletions, changes, and check).
infrastructure
infrastructureMainly write some public classes, such as configuration classes configure, constant classes constant, enumerations enum, and utility classes utils. For other layers to use.
Finally, two books are recommended for children's shoes interested in DDD
"Domain Driven Design: The Way to Deal with the Core Complexity of Software"
"Realizing Domain Driven Design"
Recommended in the past
Scan the QR code to get more exciting. Or search Lvshen_9 on WeChat , you can reply to get information in the background
1.回复"java" 获取java电子书；
2.回复"python"获取python电子书；
3.回复"算法"获取算法电子书；
4.回复"大数据"获取大数据电子书；
5.回复"spring"获取SpringBoot的学习视频。
6.回复"面试"获取一线大厂面试资料
7.回复"进阶之路"获取Java进阶之路的思维导图
8.回复"手册"获取阿里巴巴Java开发手册(嵩山终极版)
9.回复"总结"获取Java后端面试经验总结PDF版
10.回复"Redis"获取Redis命令手册，和Redis专项面试习题（PDF）
11.回复"并发导图"获取Java并发编程思维导图（xmind终极版）Another: Click [ My Benefits ] to have more surprises.