This instrument follows on from the previousAnti-DDD Schema for Relational Databases", follow the public number (Old Shaw wants to be a foreign language big brother) for information:
-
Latest Article Updates;
-
DDD framework source code (.NET, Java dual platform);
-
Add a group to chat and exchange modeling analysis and technology implementation;
-
Video and live streaming on B-site.
contexts
In our software development process, "reuse interface (webapi)", "reuse service (service)" is a very common phenomenon, many old drivers will be for their own design of the code can be "reuse Many veteran drivers feel a sense of accomplishment that their code can be "reused". However, when we look at the iterative process of the system in a longer time cycle, we will find that these "reuse", often become a stumbling block for later iterations, modifying the code will affect the whole body, and minor modifications will trigger a wide range of impacts, from this perspective, "reuse" is not conducive to the system's success. From this point of view, "reuse" is not conducive to the maintainability of the system.
Today we're going to take a deep dive into the relationship between "reuse" and DDD to open up a different perspective.
The Nature of Reuse
The following figure shows a very typical example of reuse, many developers are accustomed to provide a "save interface" to meet the "create" and "edit" scenarios:
According to our convention, "connectivity" represents "coupling", so "reusing" interfaces is essentially coupling different business scenarios together, so that when one scenario changes, it affects the other scenarios as well. When one scenario changes, it will affect the other scenarios at the same time.
It is further deduced that the coupling of two elements i.e. breaking their boundaries, they become a greater whole because of the coupling:
Whereas the value of DDD is to maintain clear boundaries, breaking boundaries is the exact opposite, so it can be concluded that breaking boundaries is anti-DDD:
Putting together the derivation process above is something like the figure below:
Stripping out the intermediate processes, we end up with the conclusion of the title "Reuse" is an "anti-DDD model":
qualifying condition
On the other hand, the term "reuse" has a broader meaning, for example, we have two systems, system A and system B both call a "payment interface", this is considered reuse "payment interface"! For example, we have two systems, system A and system B both call a certain "payment interface". In the perspective of our discussion today, this is not reuse, because both are "payment scenarios" call "payment interface", the scene is actually the same.
Then we need to qualify the scope by exploring reuse here:Reuse for different scenarios or purposes. Based on this scope we can see some typical cases of reuse:
-
RestfulAPI reuse
-
Backend Service Reuse
-
Business Middleware Reuse
And these scenarios, I believe many old drivers have had a painful experience, reuse a moment, iteration crematorium.
Don't reuse
Based on the knowledge derived from the previous section, we know that reuse, as an anti-DDD pattern, will not bring us value, but will make the system lose maintainability. Therefore, we have summarized some principles in the process of practicing DDD, and an important part of them is "don't reuse":
-
Create an API for each front-end scenario;
-
Create respective input and output entities (RequestDto, ResponseDto) for each API;
-
Create respective commands for each operation (Command);
Documentation and screenshots of the DDD principles are posted below:
/netcorepal-cloud-framework/rules-of-ddd/rules-of-ddd/
real-life project
At present, the open source DDD practice project d3shop has been launched, you can freely participate in the requirements discussion, modeling design, code contribution to the weekly model design, code for live review and discussion of the microphone, so as to help you more immersed in the experience of DDD practice to bring about growth and benefits.
Project Code:/netcorepal/d3shop