Talk about code: DDD from entry to complete entry

This article was first published on short book : https://www.jianshu.com/u/204b8aaab8ba

Version	date	Remark
1.0	2021.8.22	First article
1.1	2021.8.26	Increase the description of the core idea
1.2	2021.9.4	Strengthen the description of graphics and text for DDD is not only three to four layers of subsections

The previous DDD article- about code: reduce complexity, from abandoning the three-tier architecture to DDD entry , the whole article seems to be a simple talk about some concepts, and then a quick actual combat-many students feel that it is feedback Getting started, but not completely getting started, so we will add another one.

1. What is DDD

look at the universal Wikipedia: 16132f48cde939 Domain-driven design ( DDD ) is the concept that the structure and language of software code (class names, class methods , business variables ) . For example, if a software processes loan applications, it might have classes such as LoanApplication and Customer, and methods such as AcceptOffer and Withdraw.

This is called a concept. In my opinion, DDD is a superset of design patterns, a guiding ideology-used to guide how to decouple business systems, divide business modules, and define business domain models and their interactions.

2. The background of the birth of DDD

The concept of domain-driven design is not new. It was proposed as early as 2004 and has a history of more than ten years. However, it is well known to the public and is based on the rise of another concept, that is, microservices. Therefore, the appearance may not be exactly the same when it is implemented. More often, it is taught in accordance with the business scenario.

3. The core idea of DDD

The core idea is to isolate technical complexity from business complexity and organize business logic through a unified language to reduce cognitive costs.

The details are mainly reflected in:

• Infrastructure layer: It is responsible for isolating technical complexity and providing services internally through abstract encapsulation instead of letting internal services directly use it. This means that when the external infrastructure changes, the business will not be forced to make changes. For example, the data bus in the project is Kafka, which was later replaced by Pulsar, and the business should be unaware of it.
• Thick domain layer: Knowledge in the same domain is aggregated in one domain, and domain knowledge is no longer fragmented. This is a manifestation of the single responsibility principle.
• Entity: Replace the anemia model with the congestion model, which is fully in line with the object-oriented thinking. The objects in the business are completely projected into the entities, from resource-oriented to process-oriented and object-oriented.

4. What kind of problems can DDD solve?

General software will go through several different cycles:

1. Chimney: Each application is its own business, similar needs are repeatedly developed, and manpower is wasted
2. Servicization: Split services according to different business attributes. Focus on service splitting, service governance, model abstraction
3. Platformization: Expose related microservices as a platform. Focus on field convergence, field autonomy, and ability precipitation
4. Mid-Taiwanization: Submerge general capabilities to mid-Taiwan and quickly respond to front-end services. Need to pay attention to data connection, capability connection, and business responsiveness

major role in 16132f48cdeaa9 technology-intensive applications , especially when the application enters service-oriented and platform-oriented, it can be used in: "service split", "service governance", "domain convergence", "domain" Autonomy" played. The "data connection" in Zhongtaihua also plays a certain role.

At the micro level, DDD can effectively reduce code redundancy and the speed of demand response.

5. What to pay attention to in DDD practice

5.1 Use IOC to ensure isolation between levels

My friends often ask me, what should I do between layers? Because the boundary of the layering is not done well, the code will be coupled again and then together. The answer I gave to this is to refer to inversion of control . The common implementations are:

• Object Dependency Inject
• Service Provider Interface
• Strategy
• Abstract Factory

You can also refer to the article I wrote before: Tips: Follow Clean Architecture to write a white box test .

5.2 Module separation

Module separation is a relatively "hard" method, which makes layering no longer a convention, but a mandatory rule. In this way, when we split the microservices, the split can also be completed quickly.

5.3 DDD is not only three to four layers

Some friends also asked me, is there only three layers of DDD transfers? This is not the case. I can give two examples here:

5.3.1 Stream computing processing

We take the online data encryption application as an example: when a piece of data flows through our application, we need to encrypt it according to some conditions.


• Source operator: it will pull the message from kafka and convert it into the pojo object we need
• Map operator: Its data comes from the stream processing framework and converts a certain attribute of the pojo into an object
• Sink operator: convert the pojo object into binary data and send it to kafka

So in the code, Kafka is actually the code of the base layer. encryption belongs to the domain layer, and the glue code between map (frame) and encryption belongs to the base layer.

5.3.2 GUI Application

I believe that everyone has learned GUI or HTML programming when they were students. Then according to the DDD approach, business logic should have nothing to do with the specific interface-for example, a button (data model) on the interface will trigger an event, when the event receiver in the background receives this event, it will look for the corresponding The executor executes the corresponding logic.

In it:

• The interface can be Qt, Flex, Ios, Android, or Vue. Its essence is the user interface layer.
• The event receiver in the background is the basic layer, which plays a role as a link between the interface and the business logic.
• The specific execution logic is placed in the domain layer, which is pure logic and has nothing to do with the UI interface.