DDD is a method of dealing with complex business. There are two major parts: strategic design and tactical design.
The core of strategic design is unified language and bounded context, and the core of tactical design is independent domain logic layer.
In fact, the way to solve a complex domain system is not limited to coding architecture. We also need to consider some spillover links to deal with this complexity.
Why is complex system design complicated? It can be seen from the perspective of software development process , complex system design , and module coding .
First talk about the software development process
If a field is too complex, we generally distribute capabilities to multiple teams, which means that the realization of a complex field is often realized by a combination of multiple subsystems, sub-services, and sub-teams. How to improve the communication efficiency across teams It is necessary to ensure the consistency of communication and content.
There are two theories in software development:
Technical knowledge in the software development process improves efficiency through division of labor to establish knowledge barriers
Business knowledge in the software development process needs to eliminate knowledge barriers to improve efficiency
The improvement of the professionalism of each post requires the division of labor, so how to solve the problem of business knowledge transfer, a core model of DDD is a unified language to solve the problem of business knowledge transfer. With such a unified communication language, the unified definition and description of affairs has helped us to achieve good communication efficiency and communication effects in terms of requirement definition and problem definition.
The unified language has two meanings.
1. Unified communication language.
We have determined the meaning of business terms in advance, and we have unified cognition in all positions of business and technology, so that when we communicate, since the understanding of business terms is already at the same frequency, it will save a lot of communication costs.
2. Unified domain model and code model.
The most important knowledge accumulation of a system is code and documentation. Of course, many companies do not have documentation. When the business model is the same as the code model, it will greatly reduce the cognitive complexity of our system. If it is not the same, everyone will be confused.
Second is complexity design
In order to reduce the complexity of the business system, it is generally through the method of divide and conquer. Nowadays, the popular microservices are split based on the business dimension, so how do they split?
The idea of divide and conquer is a very important methodology to deal with software complexity design, because systems at different stages and facing different users have different sources of complexity, some from rapid business changes, and some from high concurrency scenarios. Technical complexity challenges, some come from data rules, some come from business rules, and some come from unclear system boundaries that lead to multiple R&D teams sharing a set of codes or systems.
The simplest way is the divide and conquer strategy, which disassembles the business complexity, technical complexity, and other issues of different complexity, and manages them independently to finally solve the complexity problem.
For example, when we build a middle-station system, we are actually a step-by-step process of dividing and conquering, separating functional and non-functional capabilities, basic capabilities and business capabilities, and separating the changeable from the unchanging.
The domain data model, logic & service orchestration, professional UI page design, etc. required to develop complex enterprise business systems can all be implemented on an integrated low-code development platform.
The domain-driven design idea puts forward a good starting point, which is different from the traditional methodology based on database table design system base. The domain-driven requirements are developed around the business boundary and business context.
As shown in the figure below, each point represents a domain object. When many objects are mixed together, designers or developers need to understand all domain objects, which undoubtedly increases the complexity. If you can find a way to divide the boundary reasonably, let closely related objects aggregate together (for example, the three aggregates ABC are formed in the figure below), and the aggregates interact through interfaces, then the number of interfaces will be the least. The bounded context of DDD provides a guiding idea. After the bounded context is divided, a bounded context can correspond to a microservice.
The theory that the establishment of knowledge barriers can improve efficiency is also used here. The person who develops A service does not actually need to understand the internal implementation of B service, but only needs to understand the interface provided by B. The number of domain objects of A service has been greatly reduced. It undoubtedly reduces the complexity.
Let's talk about coding implementation
The traditional three-tier structure is web, service, and dao. When a system becomes complex, if it is not restricted, a service class can reach tens of thousands of lines, which is extremely painful to maintain.
One way to solve the big mud ball at the service layer is to separate the complexity and divide the service into the application layer and the domain layer. The design principle behind the separation of business and technology. The domain layer puts business logic, and the application layer puts technical logic. The complexity is reduced, and the domain layer is easier to test.
DDD tactical design is to put business logic at the core. The same is true for tidy architecture and hexagonal architecture. Business-related code is written to entities, value objects and domain services, and some technical related codes such as transactions and caching are written to applications. Service inside.
for example
One operation of the shopping cart is to add products to the shopping cart. The application layer ShoppingCartApplicationService handles transactions and caches. The core business logic is in the domain object ShoppingCart.
The domain layer code is as follows:
The application layer code is as follows:
Of course, to implement DDD in the system, we still need to have a deeper understanding of the system and the business supported by the system before we can proceed. After all, we are still doing gradual reconstruction for most of the scenes, instead of building directly from zero to one. The structure is historically burdened.
It may take a few nights to read most of the domain modeling and business architecture data, code, and core content, and feel the epiphany. Relevant students talked from DIP to SDP, from DDD to clean architecture, and introduced the basis of layering and inversion from the mathematical model, wrapping the onion model and the hexagonal model under the same derivation, and outputting a regular The landing plan is the right way.
Write at the back
The unified language of DDD can help better transfer business knowledge in the software development process, bounded context can guide the splitting of complex systems, and tactical design can help code better layering. However, DDD provides a set of methodology and a guiding ideology. It is not necessary to use all of them. It is possible to learn from only some of them. For example, the unified language of DDD improves efficiency by reducing the transfer of business knowledge and can be applied to actual development. Methodology can provide guidance, but don’t use it mechanically, you need to tailor it according to your own situation and use it flexibly.