A preface.
Hello, everyone. Over the weekend, I opened my official account: Uncle Baiyan. Will publish a series of articles with the Nuggets, please follow me and get my tweets as soon as possible.
The DDD series Demo was urged by many readers. After a week of reference, structure and concept communication with many DDD leaders, the improved code hierarchy was finally completed.
This article will tell you about it
- Why do we use DDD?
- What systems are compatible with DDD?
- What does DDD code do and why?
You can read this article directly, but I recommend reading it first: the article introduces you to DDD. If you already know DDD, please read it directly.
Dry goods directly on, click here to view the demo code, with the code to read this article, experience deeper, don’t forget star~
DDD series blog
- A penny will take you to DDD
- Event-driven model for DDD implementation
- DDD landed storage
- The architecture layer of DDD landing
Why do we use DDD
Although I explained the reasons for using DDD in the first DDD series: Take You to DDD. However, students who are not familiar with business architecture still cannot get the advantages of DDD.
As a programmer, I still advocate everyone to think more, more solid their basic knowledge. Interview is sweet, but, after all, the interview is like an exam, more often we still need to work in a company. There’s no point in complaining about a promotion or a raise.
Without further discussion, I believe that almost 99% of Java development readers, whether you are a computing major or a multi-major, were exposed to MVC code layers when you first learned Spring or SpringBoot.
This illustrates that MVC has its own unique advantages:
- Developers can focus on just one layer of the entire structure;
- It is easy to replace an existing level of implementation with a new one;
- Layer to layer dependencies can be reduced;
- Conducive to standardization;
- It facilitates the reuse of logic of each layer.
But is this really the case? As you iterate over the functionality of your system, the business logic becomes more complex. Among the three LAYERS of MVC, V layer as data carrier and C layer as logical route are both very thin layers, and a large amount of code is piled up in M layer (model layer). A service class may have hundreds or thousands of lines, or even tens of thousands of lines, with complex nested logic and unclear main business logic. Services are a little more lightweight, and the code is the glue that holds the database execution logic together with the logic that returns control to the front end, with no clear priorities.
When you look at your project, there are so many classes and so much code that you don’t even know how to start to modify the “shit mountain” of code.
What’s the root cause?
The Service carries business logic it shouldn't have at its age.
For example: You are in charge of building a project from zero to one, and then the business gets better and better, and you hire new r&d. The service layer logic method is similar and not exactly the same. In order to be lazy, I copied your code and changed a small section of logic. So basically you’re multiplying your code by two. Similarly, with another person, your code might be multiplied by 4. However, poJOs, the data carriers, are so numerous that they are empty and you want to put logic into them, but you don’t know where to start. POJO’s anaemic model is trapped in a vicious circle.
So why can DDD solve these problems?
What is the core idea of DDD? Decoupling! Let the business is not like fried rice mixed together, but a complex process of delicious food, have their own independent practice.
In DDD’s values, any business is the responsibility of a business domain model. Domain A can only do the things of domain A. If Domain A wants to modify domain B, it needs to find an intermediary (anti-corrosion layer) to complete the operation of domain B. I want to complete a long business logic action and, after demarcating business boundaries, hand it over to the orchestration of business services (application services) to organize the business model (aggregation) to complete the logic.
In this way, each service (domain) will only do things within its own business boundaries, with minimal granularity to define the implementation of requirements. The empty anemia model was transformed into a hyperemic model. The principle of lengthy services, such as set and get values around the data carrier code irrelevant to business logic, will be removed, into the application service layer, your code is your business logic. Clear logic, high maintainability!
What kind of system is suitable for DDD
After reading the above analysis of DDD, do you think MVC comparison is rubbish? But if you think about it, DDD has been around for more than a decade, but why has it only started to come into the public eye in recent years?
I believe that those who have not read my previous DDD article can probably feel that the DDD system is not as simple as MVC structure, and the layers are definitely more complex.
So what systems are not DDD compatible?
For small and medium-sized systems with small business volume and single function, MVC architecture is undoubtedly the best choice.
The project delivery system has a short research and development cycle and customized functions according to party A’s needs from day to night.
Conversely, what is the system for DDD?
Medium – to large-scale systems, productized models, sustainable business iterations, systems with predictable business logic complexity.
To sum up:
If you don’t know DDD yet or if your system is simple, choose MVC.
You don’t know what technical architecture to use for development, business exploration phase, MVC.
At other times consider DDD as appropriate.
How and why does DDD code work
4.1. Classical layering
4.2. Dependency inversion and layering
In order to break through the dependence against its own business domain, the infrastructure is raised. When the domain service and the infrastructure have an intersection, define an interface (gray interface), and let the infrastructure to implement the corresponding interface. Interfaces themselves are between application services and domain services and exist to purify the domain layer.
The advantage of this is that, from the perspective of subcontracting logic, the upper layer is dependent on the lower layer, and the lower business domain is not dependent on either party, and the domain is independent.
4.3.DDD layered request invocation chain
This will increase authorization
1. The user interaction layer initiates a request
2. Apply the service layer to arrange the business logic [only do method arrangement, not deal with any logic]
3. If the orchestration logic depends on three-party RPC, define Adapter. The three-party service field affects the service.
4. If the orchestration logic depends on other domain services and application services, it can be directly called without transformation. However, if the current framework does not meet the requirements, such as sending SMS messages, it is better to go through the adapter, the carrier changes, depending on the application service may be different.
5. Aggregation of the business that cannot be handled by itself is processed at the domain layer, and a layer of interfaces (gray anticorrosion layer) is established based on the inversion principle to place the coupling between the domain layer and the basic Settings.
6. After the logical processing, call the warehouse aggregation method.
4.3.2. Query
CQRS model, different from add, delete and modify application service, is query application service. You don’t have to follow the DDD layering rules (no changes to the data). Simple logic can even be invoked directly by the Controller layer to return data from the repository layer.
In live.
One of the logic that runs through DDD hierarchically from start to finish is decoupling. If you’re a really extreme believer, each layer, each step will add an adapter. I think this is too painful for research and development, but there should be a balance between architecture and actual research and development.
Vi. Special thanks
lilpilot
Seven. Contact me
If there is an incorrect place in the article, welcome to correct, writing the article is not easy, point a thumbs-up, yao yao da ~
Nailing: louyanfeng25
WeChat: baiyan_lou
Public account: Uncle Baiyan
