Why DDD 1 microservice design chooses DDD
Posted May 30, 2020 • 5 min read
If your team is currently building a microservice architecture style software system, ask yourself two questions?
Software architecture evolution
The software architecture has generally gone from stand-alone architecture, centralized architecture, distributed micro-service architecture, the program hierarchy diagram is shown below.
Features are as follows:
Process-oriented design method;
The structure is CS;
The level of the program is divided into two layers, namely the UI layer and the database layer;
The core of the design is the database and fields.
Features are as follows:
Object-oriented design method;
The program level is a classic 3-layer architecture, namely, service access layer, business logic layer, and database layer;
Some enterprises also adopt SOA architecture style;
The disadvantages of centralized architecture:scalability and poor scalability, the system is easy to become bloated;
Distributed microservice architecture
Based on the concept of microservices:divide and conquer, high cohesion of modules(independent team, independent deployment, independent storage, heterogeneous technology), and RPC or HTTP communication between modules, loose coupling;
Loose coupling between modules, which solves the problems of scalability and scalability;
Monolithic architecture and centralized architecture, system analysis, system design, and system development are divided into three stages, that is, three different people or groups or positions are responsible. Such consequences are:
The information in the three stages of system analysis, design and development is inconsistent, resulting in a large deviation between the function and the demand after going online;
The development of the system cannot quickly respond to changes in demand and business, and misses the opportunity for development.
The dilemma of microservices
Problems solved by microservices
Microservices solve the problems of monolithic architecture and centralized architecture:scalability, elastic scaling, and agile development to quickly respond to business changes;
But microservices are not without flaws.
The challenge of microservices
What should be the granularity of microservices? How should microservices be split and designed? Where are the boundaries of microservices?
The creator of the microservice architecture, martin flower, did not tell us how to split the microservices.
The dilemma of microservices splitting:
Examples of failure:Microservices are technical frameworks that are small enough to be independently deployed. Then, because the split is too fine, later service operation and maintenance and online.
The essence of the problem:What is the boundary of the business or microservices?
The way to break the game:DDD released in 2004, Domain-Driven Design Tackling Complexity in the Heart of Software, tracking the core complexity of the software.
The core idea:Define the domain model through the domain-driven design method to determine the boundary between the business and the application, and finally ensure the consistency of the business model and the code model.
\ * \ *
A lot of practice in the industry has proved that:The domain model is designed through the DDD method, the domain boundaries are divided, and the boundaries of microservices are divided from the business perspective according to the domain boundaries. The microservices designed through these boundaries are very reasonable and can be implemented. The service has high internal cohesion and low external coupling.
\ * \ *
\ * \ *
Therefore, many enterprises have regarded DDD as the mainstream method of microservice design.
It is a design idea that deals with highly complex domains:** Domain modeling around business concepts to control the complexity of the business, and attempts to separate the complexity of technical implementation, to solve the complexity of software systems that are difficult to understand and evolve;
Not an architecture, but an architectural design methodology:Simply simplify complex business areas through boundary division, help us design clear domains and application boundaries, and easily realize the evolution of architecture.
Divided into strategic design and tactical design.
What did DDD bring?
From a business perspective, establish a business domain model, divide the boundaries of the domain, and establish the delimitation context of the general language. The bounding context is the reference of the microservice boundary.
The domain model is used to guide the design and disassembly of microservices.
Domain model, domain boundary, general language boundary context;
Steps to delineate the domain model and microservices boundary:
From a technical perspective, it focuses on the technical realization of the domain model and completes the development and landing of the software.
Contains basic elements:
Application services and
Wait for the design and implementation of code logic.
Correlate the domain objects in the domain model with the objects in the code model, and bind the business architecture with the system architecture. When we adjust the business architecture and domain model, the system architecture will also adjust the mapping relationship;
Relationship between microservices and DDD
The main answer is why the design and boundaries of microservices need to use DDD methodologies to operate. I hope your microservices will be designed with high cohesion and low coupling, adapt well to business changes, and have very good scalability and scalability.
Originality is not easy, pay attention to sincerity, and the forwarding price is higher! Reprint please indicate the source, let us communicate with each other, make progress together, welcome to communicate.
I will continue to share Java software programming knowledge and the career path of programmers. Welcome to pay attention. I have organized various resources for programming and learning over the years, pay attention to the public number "Li Fuchun continuous output", and send "learning materials" to you!