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
We know that architectural patterns for software have changed a lot over the years as devices and new technologies have evolved. Generally speaking, the software architecture pattern has experienced 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.
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?
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 .
DDD strategic design will establish a domain model, which can be used to guide the design and split of microservices. The first step of DDD is to create an event storm, which can be understood as discussing the understanding of the business together. The main purpose is to decompose our business domain as much as possible. 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.
Specifically, we can determine the domain model and microservice boundaries in three steps .
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.
The relationship between DDD and microservices.
DDD 是一种架构设计方法，微服务是一种架构风格，两者从本质上都是为了追求高响应力，而从业务视角去分离应用系统建设复杂度的手段。两者都强调从业务出发，其核心要义是强调根据业务发展，合理划分领域边界，持续调整现有架构，优化现有代码，以保持架构和代码的生命力，也就是我们常说的演进式架构。
DDD 主要关注：从业务领域视角划分领域边界，构建通用语言进行高效沟通，通过业务抽象，建立领域模型，维持业务和代码的逻辑一致性。
微服务主要关注：运行时的进程间通信、容错和故障隔离，实现去中心化数据管理和去中心化服务治理，关注微服务的独立开发、测试、构建和部署。