Why can DDD catch fire?
Let’s not discuss the definition of DDD, but sort out the background of the popularity of DDD. According to the routine I learned, it is always why first, then what problems to solve, what things to use, and finally how to use. We all know that in recent years, with the development of equipment and technology, software architecture has changed a lot, from the original single machine (BS / CS) architecture to the later centralized architecture, and then to today’s microservice architecture.
Now is basically the era of the prevalence of micro service architecture. DDD was proposed by Eric Evans as early as 2004, but it has been in a state of indifference until Martin Fowler’s microservices attracted everyone’s attention, that is, after the prevalence of micro services (it should be noted that the earliest proponent of micro services was not Martin Fowler, but Fred George),DDD is back in people’s view again. Why?
Evolution of Architecture-
Let’s first look at the evolution and main differences of the three technical architectures:
The first stage is stand-alone architecture, which is characterized by the design and development of the whole development around the database.
The second stage is the three-tier centralized architecture, which adopts the object-oriented design method. The business logic is divided into business layer, logic layer and data access layer. This architecture is easy to become bloated in one or more layers and has poor scalability. In addition, Moore’s law fails and the performance of a single machine is limited.
The third stage is the micro service architecture. In the centralized architecture, the system analysis, design and development are often carried out independently, and the principals of each stage may be different, so it involves the loss of exchange information. In addition, the process from analysis to development of the project is very long, and it is easy to finally develop the design which is different from the realization of the requirements. The micro service is mainly to solve these pain points in the second stage, Realize the decoupling between applications and solve the problem of single application scalability.
Problems in microservices-
After entering the micro service, many problems of single application with centralized architecture have been solved, but new problems have emerged. How big should the granularity of micro service be? How to design microservices? How to split microservices? Where is the boundary of microservices?
People haven’t solved this problem for a long time. Even Martin Fowler didn’t tell us how to split microservices when he proposed the microservice architecture.
Even for a long time, people have some misunderstandings about the splitting of microservices. Some people believe that “microservices are very simple, that is, splitting the previous single application into multiple deployment packages, or replacing the original single application architecture with a set of technical architecture supporting microservices, even microservices.” Others believe that micro services should be split as small as possible.
In view of the above situation, many projects are too complex due to excessive splitting in the early stage, which makes it difficult to operate and even go online in the later stage.
We can draw a conclusion: the root cause of the dilemma of micro service splitting is that we don’t know where the boundary of business or micro service is. In other words, once the business boundary and application boundary are determined, this dilemma will be solved.
DDD solves the problem of determining business boundaries. It can be seen that DDD is not a technical architecture, but a methodology for dividing the scope of business areas. The rise of DDD is due to the fact that many engineers familiar with Domain Driven Modeling (DDD) find that business combing with the idea of DDD can well plan the service boundary and realize the “high cohesion and low coupling” inside and outside microservices. Therefore, more and more people take DDD as the guiding ideology of business division.
So, what is DDD?
Overview of DDD-
Through the above study, we can know that DDD is a method of disassembling business, dividing business and determining business boundary. It is a highly complex domain design idea. It divides our problems into domains and tries to separate the complexity of technical implementation. It mainly solves the problem that software is difficult to understand and evolve. DDD is not an architecture, but an architecture methodology, which aims to simplify the field of complex problems, Help us design clear fields and boundaries, which can well realize the evolution of technical architecture.
DDD consists of two parts, strategic design and tactical design:
Strategic design mainly starts from the business perspective, establishes the business domain model, divides the domain boundary, and establishes the boundary context of the common language. The boundary context can be used as the reference boundary of microservice design.
From a technical perspective, tactical design focuses on the technical implementation of domain model and completes software development and implementation, including the design and implementation of code logic such as aggregation root, entity, value object, domain service, application service and resource base.
DDD strategic design will establish a domain model. These four words together will make people feel very profound. In fact, it is a paper tiger. Generally speaking, it is a model that simulates a domain. This model is more abstract, but it is convenient for people to communicate. For example, there is a peach tree in the park. How should we study it if we want to study it well? Are peaches delicious? Is it expensive? varieties? How to plant? Where is it planted? Make a peach wood sword? The medicinal value of peach leaves?
You see, it’s reasonable to study every problem in this way, but it’s very chaotic. Recall that it’s studied in the biology book of junior middle school?
First divide the plant into multiple organs according to everyone’s understanding, such as peach, peach leaf, peach flower, etc., then subdivide each organ into tissues according to its function, and then divide it into different cells according to the morphology and other functions of each cell in the tissue. See if this is a very organized analysis method.
The same is true of DDD. When we face the complex business of peach tree, we first divide it into multiple organs (fields) according to our inherent understanding, and then divide it into multiple organizations (aggregation) according to some dimensions (here is function), and each organization is composed of many cells (entities). This is a strategy. What are the benefits?
We can ensure that the boundaries we discuss, that is, the things we discuss are one dimension of a field. For peach trees, peaches, peach flowers, peach leaves and tree trunks are different fields. The boundaries that divide different fields are called domain boundaries. When we determine these fields, we can ensure that we are discussing things in the same field, The advantage of this is that we can specify some concepts, or terms, and minimize the loss of information when we discuss it in the future.
DDD strategic design will establish a domain model, which is used to guide the design and splitting of micro services. The first step of DDD is to brainstorm, which can be understood as discussing the understanding of the business together. The main purpose is to decompose our business areas as much as possible. Just like the peach tree, the first thing to do is to analyze as much as possible to ensure that every field can be paid attention to, In practice, use case analysis, scenario analysis and user journey analysis are often used, which is a divergent process. In the brainstorming stage, many domain objects such as entities, commands and events will be generated. We cluster them from different dimensions to form boundaries such as aggregation and bounding context, and establish domain models, which is a convergent process.
Specifically, we can determine the domain model and micro service boundary 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 according to these elements.
Step 2: according to the business relevance between domain entities, combine the entities closely related to the business to form aggregation, and determine the aggregation root, value object and entity in the aggregation. In this figure, the boundary between aggregations 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 business and semantic boundaries and other factors, define one or more aggregations in a bounded context to form a domain model. In this figure, the boundary between the boundary contexts is the second boundary, which may be the boundary of future microservices. The domain logic in different boundary contexts is isolated to run in different microservice instances, which are physically isolated from each other, so it is a physical boundary, and the boundaries are represented by solid lines.
In addition to domain, aggregation and entity, there are also words such as aggregation root and value object. In addition, there are unified modeling language, sub domain, core domain, general domain and support domain. In fact, they are all paper tigers. As mentioned earlier, in order to facilitate the discussion of a certain field, some concepts will be formed, and these concepts will be summarized by some nouns. That’s how the above nouns come from, which is called unified modeling language, Hahaha, OK, no nonsense. I’ll explain the meaning of these words in my later articles. Here we mainly discuss what problems DDD solves.
Sort it outDDD and microservicesDDD is an architecture design method, and microservice is an architecture style. In essence, both are means to separate the construction complexity of application system from the business perspective in order to pursue high responsiveness. Both emphasize starting from the business, and its core meaning is to reasonably divide the domain boundary according to the business development, continuously adjust the existing architecture and optimize the existing code, so as to maintain the vitality of the architecture and code, that is, the evolutionary architecture we often call.
DDD mainly focuses on: dividing domain boundaries from the perspective of business domain, building a common language for efficient communication, establishing domain model through business abstraction, and maintaining the logical consistency of business and code.
Microservices mainly focus on inter process communication, fault tolerance and fault isolation at runtime, decentralized data management and decentralized service governance, and independent development, testing, construction and deployment of microservices.
This article mainly discusses the reasons why DDD is popular, what industry problems have been solved, the main ideas of DDD and the general implementation steps of DDD.
Finally, we can think about a small question: is single application suitable for DDD?
Author: Persian code
Source: cnblogs com/bossma/p/9858847. html