Location>code7788 >text

Figure of speech - all anti-DDD models are garbage

Popularity：613 ℃/2024-09-04 08:10:13

This instrument follows on from the previousSubjective and objective, breaking the spell of DDD based on experience", follow the public number (Old Shaw wants to be a foreign language big brother) for information:

  1. Latest Article Updates;

  2. DDD framework source code (.NET, Java dual platform);

  3. Add a group to chat and exchange modeling analysis and technology implementation;

  4. Video and live streaming on B-site.

Just kidding.

"I'm not addressing this one issue, I'm saying all anti-DDD models are garbage", as a coach, I often use this kind of joke in the team to tease the judgment logic and decision results that do not conform to the DDD values, and point out where the specific points of non-conformity are, and since we already know each other very well, we are able to quickly react to it As we already know each other very well, we can react quickly and build consensus, so that we can constantly revise the decision logic and decision results, so that the scope of the problem and the solution converge in a certain range, and continuously maintain control over the complexity of the system.

===

pre-conditions

It is first necessary to align the scenarios we are discussing, mainly within the following conditions:

  1. Software systems are iterative over time

  2. Software systems are business-oriented systems

In this range of conditions, we can read:

  1. We believe that the cost of iteration is an important part of the cost of software

  2. We believe that the business complexity of the software systems we build is higher than the technical complexity

Cost and Complexity

In order to minimize the combined cost of system iterations, it is essentially about controlling system complexity, which is composed of a combination of business complexity and technical complexity.

In order to realize the goal of "mastering system complexity", we have the following ideas based on the law of conservation of complexity:

  1. Complexity cannot be eliminated, only transferred

  2. Respect the inherent complexity of the business

  3. Avoid introducing additional technical complexity

And we're in theAbout domain-driven design, everyone understands it wronglyThe paper "Deriving Conclusions about Complexity:

  1. System complexity is related to the number of elements and the relationship of the elements;

  2. The relationships of the elements have a much greater impact on the complexity of the system than the number of elements would have;

===

Core views

If you've been following theLao Xiao's path to domain-driven designThe series has been read all the way through, so our next derivation process needs to build on the cognitive foundation previously constructed, and the core ideas are listed here for review:

  1. Domain-driven design is a value

  2. DDD values: clear boundaries are the most important thing

  3. Software Long-Termism: Maintainability is the Most Important Thing

  4. DDD is the first principle of software engineering

Based on these points above, the core of DDD, is to control the relationship between the system elements, clear boundaries, to control the complexity in a limited range, completely matching the logic of cost control of software engineering, then is it possible to draw the following conclusions:

  1. Compliance with DDD values means compliance with the cost benefits of software engineering

  2. The anti-DDD model implies that the cost benefits of software engineering are not met

So going back to the title of this article, "All Anti-DDD Patterns are Rubbish", a more accurate description would be "All Anti-DDD Patterns are Not in the Interest of Software Engineering Costs", and I think that this logic is valid.

If you agree with theIs DDD the first principle of software engineering?The point of the article, then the same conclusion can be drawn that violating the first principles of software engineering is, of course, counterproductive and leads to the abyss of a system that is rapidly spiraling out of control.

So, I'm sorry, if your software design thinking is not centered around "clarifying and maintaining boundaries", then the probability is that it's the wrong value judgment, and the probability is that the complexity of the system is difficult to control, and the phenomenon that comes out of the figurative phenomenon is what we often say, "Iteration doesn't work anymore! ".

So, come practice DDD with me!

<Previous