Why is DDD so popular?

Let’s not discuss the definition of DDD first, first sort out the background of DDD popularity, according to the routine I learn, is always why first, then what problem to solve, what is the thing, and finally how to use. As we all know, software architecture has changed a lot with the development of equipment and technology over the years, from the original single machine (BS/CS) architecture to the later centralized architecture, and now the microservice architecture. It can be said that the era of microservice architecture is prevailing now. DDD was proposed by Eric Evans in 2004. But it didn’t warm up until Martin Fowler’s Microservices caught everyone’s attention, and that’s when Microservices took off (it should be noted that Microservices were first introduced not by Martin Fowler, but by Fred George), DDD is back on the radar again. Why?

Let’s take a look at the evolution of the three technology architectures and the main differences:

The first stage is stand-alone architecture, characterized by the whole development around the database design and development.

The second stage is the three-tier centralized architecture, which adopts the object-oriented design method, and the business logic is divided into business layer, logic layer and data access layer. This architecture is easy for a layer or several layers to become bloated and 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 a centralized architecture, the system analysis, design and development tend to be independent, and may not be the same, head of the stages, it involves the exchange of information loss problem, another project from the analysis to the development experience of the process is very long, very easy to implement development final design and the demand of different, Microservices mainly solve these pain points in the second stage, realize the decoupling between applications, and solve the problem of single application scalability.

Problems with microservices

After entering microservices, many problems of single application of centralized architecture have been solved. However, a new problem arises at the historic moment. How much strength should microservices have? How are microservices designed? How to split microservices? Where are the microservice boundaries?

People haven’t solved this problem for a long time, even Martin Fowler didn’t tell us how to break up microservices when he proposed the microservices architecture.

Even for a long time, there was some misunderstanding about the microservices split. Some people thought that “microservices are as simple as splitting the original monolithic application into multiple deployment packages, or replacing the original monolithic application architecture with a set of technical architecture that supports microservices, as microservices.” Others think microservices should be broken up as small as possible.

In view of the above situation, many projects are too complicated due to excessive splitting in the early stage, which makes it difficult to operate and maintain or even to go online in the later stage.

One conclusion can be drawn: The root cause of the microservices unwrapping dilemma is not knowing exactly where the boundaries of the business or microservices lie. In other words, with business and application boundaries defined, the dilemma is solved.

DDD solves this problem of defining business boundaries, so DDD is not a technical architecture, but a methodology for demarcating business domains. The rise of DDD is due to the fact that many engineers familiar with domain-driven modeling (DDD) found that business combing with DDD ideas can well plan service boundaries and achieve “high cohesion and low coupling” inside and outside microservices when designing microservices. So more and more people regard DDD as the guiding ideology of business division.

So, what is DDD?

DDD overview

Through the above study can know a DDD is disassembled, divide the business and identify business boundary, the method of design is a highly complex domain, will be our problem into a regional, trying to separate technical implementation complexity, main is to solve the software is difficult to understand the evolution of the problem, DDD is not a kind of architecture, Rather, it is an architectural methodology that aims to simplify the domain of complex problems and help us design clear domains and boundaries for the evolution of technical architectures. DDD consists of two parts, strategic design part and tactical design part

Strategic design mainly starts from the business perspective, establishes the business domain model, divides the domain boundary, establishes the universal language bound context, the bound context can be used as the reference boundary of microservice design.

Tactical design focuses on the technical implementation of domain model from the technical perspective, completing 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 strategy designed to build the domain model, these four words put together can let a person feel very advanced, in fact is a paper tiger, it is simulated in the field of a popular a kind of model, this model is an abstract, but facilitate people to communicate, for example: the park there is a peach tree, if we want to have a good peach tree how to study?

Are peaches delicious? Is it expensive? Breed? How to grow it? Where to plant it? Mahogany swords? Medicinal value of peach leaf?

You see, it makes sense to study every question in this way, but it’s very confusing. Remember the middle school biology book that studied it this way?

First divide the plant into multiple organs according to our understanding, such as peaches, peach leaves, peach blossoms and so on, and then divide each organ into tissues according to its function, and then divide each cell into different cells according to the shape of the tissue and so on. You see if this is a very methodical analysis method.

DDD, too, when we are faced with this complex business peach, first according to the understanding of the inherent into multiple organ (areas), and then according to certain dimensions of each area (here is) is divided into multiple organizations (polymerization), and each organization is composed of many cells (entity), which is a kind of strategy, what are the benefits? We can make sure that the boundaries that we’re talking about, the things that we’re talking about are one domain and one dimension. For peach trees, peaches, peach blossoms, peach leaves, tree trunks are all different domains. The boundaries that divide different domains are called domain boundaries. We can make sure that we’re talking about parts of the same field, and the advantage of that is that we can define some concepts, or terminology, so that as little information is lost when people talk about it later.

DDD strategic design establishes the domain model, which is used to guide the design and fragmentation of microservices. The first step of DDD is to brainstorm, which can be interpreted as a discussion of the business understanding. The main purpose is to break down our business domain as thoroughly as possible, like the peach tree. The first thing to do is to do as much analysis as possible to make sure that each area is covered. In practice, use case analysis, scenario analysis, and user journey analysis are often used. This is a divergent process, and the brainstorming stage produces a lot of entities, commands, events, and other domain objects. We cluster from different dimensions to form boundaries such as aggregation and bounded contexts to build domain models, which is a convergence process.

Specifically, there are three steps to determine the domain model and microservice boundaries.

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: Combine entities closely related to the business to form an aggregation based on the business relevance between domain entities, and identify aggregate roots, value objects, and entities in the aggregation. In this figure, the boundary between the aggregations is the first-level boundary, running in the same microservice instance. This boundary is the logical boundary, so it is represented by a dotted line.

Step 3: The domain model is formed by delineating one or more aggregations within a bounded context based on business and semantic boundaries. In this figure, the boundary between bounded contexts is the boundary of the second layer, which may be the boundary of future microservices. The domain logic in different bounded contexts is isolated in different microservice instances and physically isolated from each other, so it is the physical boundary. Solid lines are used to represent the boundary.

In addition to the above areas, polymerization, polymerization root emerged in the outside entities, value objects, such as words, in addition to the unified modeling language, child domain, core domain, general domain, support domain and so on, actually are paper tigers, said earlier in order to facilitate the discussion about some field tend to form some concepts, these concepts have some nouns, This is where the above term comes from, and it’s called unified Modeling Language (UML), hahaha, well, no nonsense, I’ll explain what these terms mean in a later article, but here’s what DDD solves.

Let’s review the relationship between DDD and microservices. DDD is an architectural design method, while microservices is an architectural style. Both are essentially means of separating the complexity of application system construction from a business perspective in pursuit of high responsiveness. Both emphasize to start from the business, the core of which is to emphasize the rational division of domain boundaries according to business development, continuous adjustment of existing architecture, optimization of existing code, so as to maintain the vitality of architecture and code, which is often referred to as the evolutionary architecture. DDD focuses on: demarcating domain boundaries from a business domain perspective, building a common language for efficient communication, building domain models through business abstraction, and maintaining logical consistency between business and code. Microservices are the main link

Note: Interprocess communication, fault tolerance and fault isolation at runtime, decentralized data management and decentralized service governance, focus on independent development, testing, construction and deployment of microservices.

In summary, this article mainly discusses the reasons why DDD is popular, what industry problems it solves, the main ideas of DDD, and the implementation steps of DDD.

Six quick questions: Is singleton application suitable for DDD?