Table of contents
The Evolution of Software Architecture Patterns
The Dilemma of Microservice Design and Separation
Why is DDD suitable for microservices?
DDD includes two parts: strategic design and tactical design.
We can use three steps to delineate the boundary between the domain model and microservices.
We know that the microservice design process often faces the problem of how to demarcate boundaries. I often see project teams arguing about how small microservices should be dismantled. Different people will split different microservices according to their own understanding of microservices, so everyone insists on their own opinions, and no one can convince anyone, and they all feel that they are very reasonable.
In the actual implementation process, I have indeed seen that many projects are completed by patting their heads when faced with this kind of microservice design confusion. The pressure of operation and maintenance after going online can be imagined. Is there a suitable theory or design method to guide the design of microservices? When you see the title of this lecture, I think you already know the answer.
That's right, it's DDD. So today I will give you a detailed explanation: "Why should domain-driven design be chosen for microservice design?"
The Evolution of Software Architecture Patterns
With the development of equipment and new technologies over the years, the architectural model of software has undergone great changes. Generally speaking, the software architecture pattern has undergone three stages of evolution from stand-alone, centralized to distributed microservice architecture. With the rapid rise of distributed technology, we have entered the era of microservice architecture.
Let's first analyze the three stages of the evolution of software architecture patterns.
The first stage is stand-alone architecture : using process-oriented design method, the system includes two layers of client UI layer and database, using C/S architecture mode, the whole system is designed and developed around the database driver, and always starts from the design of database and fields .
The second stage is the centralized architecture: adopting the object-oriented design method, the system includes business access layer, business logic layer and database layer, using the classic three-tier architecture, and some applications adopt the traditional SOA architecture. This architecture tends to make the system bloated, with poor scalability and elastic scalability.
The third stage is the distributed microservice architecture : with the introduction of the microservice architecture concept, the centralized architecture is evolving towards the distributed microservice architecture. The microservice architecture can well realize the decoupling between applications and solve the problem of insufficient scalability and elastic scalability of single applications.
We know that in the era of stand-alone and centralized architectures, system analysis, design, and development are often carried out independently and in stages.
For example, in the process of system construction, we often see such a situation: A is responsible for proposing requirements, B is responsible for requirement analysis, C is responsible for system design, and D is responsible for code implementation. It is easy to cause information loss. In the end, it is easy to cause inconsistencies between requirements, design, and code implementation. Often after the software is launched, we find that many functions are not what we want, or the functions we made deviate too much from our own requirements.
Moreover, under the two modes of stand-alone and centralized architecture, the software cannot quickly respond to rapid changes in demand and business, and ultimately misses the opportunity for development. At this time, the emergence of distributed microservices is a bit at the right time.
The Dilemma of Microservice Design and Separation
After entering the era of microservice architecture, microservices have indeed solved many problems of the original single application with centralized architecture, such as scalability, elastic scalability, agile development of small-scale teams, and so on.
But while seeing these benefits, there have also been a lot of debates and doubts in the practice of microservices: How big should the granularity of microservices be? How should microservices be split and designed? Where should the boundaries of microservices be?
It can be said that there has not been a set of systematic theories and methods to guide the splitting of microservices for a long time, including Martin Fowler, the proposer of the microservice architecture model, when he proposed the microservice architecture, he did not tell us how to split microservices. Serve.
Therefore, during this long period of time, many people have misunderstood the understanding of microservices. Some people think: "Microservices are very simple, but it is just to split the original single package into multiple deployment packages, or replace the original single application architecture with a set of technical frameworks that support the microservice architecture, even if it is a microservice." Some people said: "Microservices, that is, they need to be micro and small. The smaller the demolition, the better the effect."
But I think that in the past two years, you must have heard of some projects in the technical circle because of the excessive splitting of microservices in the early stage, which made the project too complex and unable to go online and operate and maintain.
On the whole, I think the root cause of the dilemma of microservice splitting is not knowing where the boundaries of business or microservices are. In other words, once the business boundary and application boundary are determined, this dilemma will be solved.
So how to determine whether there is relevant theory or knowledge system support? Before answering these questions, let's take a look at the past and present of domain-driven design and microservices.
In 2004, Eric Evans (Eric Evans) published the book "Domain-Driven Design - Tackling Complexity in the Heart of Software", from which Domain Driven Design (DDD for short) born. The core idea of DDD is to define the domain model through the domain-driven design method, so as to determine the business and application boundaries, and ensure the consistency between the business model and the code model.
However, after DDD was proposed, it has always been "thunderous, but rainy" in the field of software development! It wasn't until Martin Fowler proposed the microservice architecture that DDD really ushered in its own era.
Some software engineers who are familiar with the DDD design method find that they can use the DDD design method to establish a domain model when designing microservices, divide the domain boundaries, and then divide the microservice boundaries from a business perspective based on these domain boundaries. However, the business and application boundaries of microservices designed according to the DDD method are very reasonable, which can well achieve "high cohesion and low coupling" inside and outside microservices. So more and more people began to use DDD as the guiding ideology of microservice design.
Now, many large Internet companies have adopted the DDD design method as the mainstream design method for microservices. DDD has also started to become really hot from the past "big thunder, little rain".
Why is DDD suitable for microservices?
"I searched for him thousands of times in the crowd. Looking back suddenly, the man was in a dimly lit place." After years of confusion and disputes, Microservice finally found his sweetheart.
So where is DDD sacred, and what artifact does it have?
DDD is a design idea for dealing with highly complex fields. It tries to separate the complexity of technical implementation, and builds a domain model around business concepts to control the complexity of the business, so as to solve the problem that software is difficult to understand and difficult to evolve. DDD is not an architecture, but an architecture design methodology. It simplifies complex business domains through boundary division, helps us design clear domain and application boundaries, and can easily realize architecture evolution.
DDD includes two parts: strategic design and tactical design.
Strategic design mainly starts from the business perspective, establishes a business domain model, divides domain boundaries, and establishes a bounded context of a common language. The bounded context can be used as a reference boundary for microservice design.
Tactical design starts from a technical perspective, focuses on the technical realization of the domain model, and completes software development and implementation, including the design and implementation of code logic for aggregate roots, entities, value objects, domain services, application services, and resource libraries.
Let's take a look at how DDD does strategic design.
DDD strategic design will establish a domain model, which can be used to guide the design and split of microservices. Event storm is the main method to build domain model, it is a process from divergence to convergence. It usually uses use case analysis, scenario analysis and user journey analysis to decompose the business domain as comprehensively as possible and sort out the relationship between domain objects. This is a divergent process. The event storm process will generate many domain objects such as entities, commands, and events. We cluster these domain objects from different dimensions to form boundaries such as aggregation and bounded context, and establish domain models. This is a convergent process.
We can use three steps to delineate the boundary between the domain model and microservices.
Step 1: sort out user operations, events, and external dependencies in the business process in the event storm, and sort out domain objects such as domain entities based on these elements.
Step 2: According to the business correlation between domain entities, combine closely business-related entities to form an aggregation, and determine the aggregation root, value object, and entity in the aggregation. In this figure, the boundary between aggregates is the first layer boundary, they run in the same microservice instance, this boundary is a logical boundary, so it is represented by a dotted line.
Step 3: According to factors such as business and semantic boundaries, define one or more aggregates in a bounded context to form a domain model. In this figure, the boundary between bounded contexts is the second layer boundary, which may be the boundary of future microservices. The domain logic in different bounded contexts is isolated and run in different microservice instances, physically interacting with each other. Isolation, so it is a physical boundary, and the boundary is represented by a solid line.
With these two layers of boundaries, the design of microservices is not difficult.
In the strategic design, we established the domain model, delineated the boundaries of the business domain, established a common language and bounded context, and determined the relationship between various domain objects in the domain model. At this point, the design of the business-side domain model is basically completed, and this process also basically determines the micro-service boundaries on the application side. In the process of landing from business model to microservice, that is, from strategic design to tactical design, we will establish a mapping relationship between the domain objects in the domain model and the code objects in the code model, and integrate the business architecture and system The schema is bound. When we adjust the business architecture and domain model in response to business changes, the system architecture will also be adjusted at the same time, and a new mapping relationship will be established simultaneously.
The relationship between DDD and microservices is
With the above explanation, now we might as well summarize the relationship between DDD and microservices again.
DDD is an architectural design method, and microservice is an architectural style. Both of them are essentially means to pursue high responsiveness and separate the complexity of application system construction from a business perspective. Both emphasize starting from the business, and their core essence is to emphasize the rational division of domain boundaries according to business development, continuously adjust the existing architecture, and optimize the existing code to maintain the vitality of the architecture and code, which is what we often call an evolutionary architecture. .
DDD mainly focuses on dividing domain boundaries from the perspective of business domains, building a common language for efficient communication, establishing domain models through business abstraction, and maintaining logical consistency between business and code.
Microservices mainly focus on: inter-process communication, fault tolerance and fault isolation during runtime, realize decentralized data management and decentralized service governance, and focus on independent development, testing, construction and deployment of microservices. Establish a domain model to maintain the logical consistency of business and code. Microservices mainly focus on: inter-process communication, fault tolerance and fault isolation during runtime, realize decentralized data management and decentralized service governance, and focus on independent development, testing, construction and deployment of microservices.
Summarize
Overall, DDD can bring you the following benefits:
1. DDD is a complete and systematic design method, which can bring you a standard design process from strategic design to tactical design, making your design ideas clearer and the design process more standardized.
2. DDD is good at dealing with domain-related product development with high-complexity business. Through it, a core and stable domain model can be established, which is conducive to the transfer and inheritance of domain knowledge.
3. DDD emphasizes the cooperation between the team and domain experts, which can help your team establish a good communication atmosphere and build a consistent architecture system.
4. The design ideas, principles and patterns of DDD help to improve your architectural design capabilities.
5. Whether you are designing microservices in a new project or evolving the system from a single architecture to microservices, you can follow the architectural principles of DDD.
6. DDD is not only applicable to microservices, but also to traditional monolithic applications.