This instrument follows on from the previousThe Best Path to Learning True DDD", 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.
The mysterious "empirical"
There are a thousand Hamlets in the eyes of a thousand people, and everyone has different experiences and different perceptions, so they have different perspectives and feelings about Hamlet. In the field of software engineering, there is also a famous viewpoint on how to do a good job of software design: "by experience". However, "by experience" means that it can not be replicated. If software design can only be based on experience, then it is better to say that it is lucky.
Read the previous article in this series, "TheLao Xiao's path to domain-driven designFor those of you who have read the article, you should know that I take the opposite view of this, and today, through a few minutes of space, I present my understanding in an attempt to break the spell of empirical experience.
rely on experience and subjective judgment
First of all, I believe that relying on experience to make decisions is essentially a subjective judgment, especially those that cannot be deduced from objective facts and logic and those that do not allow for the establishment of a general consensus. At least the very method of relying on experience is subjective. Imagine if people rely solely on their own past experience to make judgments, then "go left" and "go right" will become a common conflict of opinion, and the back of this conflict is, "I don't want you to feel, I want me to feel". I don't want you to think, I want me to think".
Of course it would be more accurate to say that "empirical" implies a lack of absolute objectivity.
Subjective and objective
The opposite of subjectivity is objectivity, and objectivity means that the viewpoint is based on objective facts, based on a chain of deduced logic that conforms to the facts, which means objective decision-making, and the ability to establish a consensus judgmental result within a certain set of rules, then we can get the following viewpoint:
-
Subjective judgments correspond to non-standardization and cannot be standardized
-
Objective judgments correspond to criteria that can be standardized
If it is possible to standardize judgments about something, doesn't that mean that it is executable and implementable?
Subjectivity and objectivity in requirements analysis and modeling design
Let's start with an example, let's say we have a need: "Organize the items in the room", then our solution could be "Take N organizers and put the items in them one by one", then there is some subjective and objective decision making going on here.
The subjective part is there:
-
Decide how many organizers to use
-
Which items go in which organizer
The objective part there:
-
Organizers are independent of each other
-
One item won't fit in two bins.
This can be the case if we correspond the item and the organizer to the modeling design, where the organizer contains the item and the software is the domain model responsible for the satisfaction of the requirement points:
-
Items correspond to demand points
-
The corresponding domain model of the organizer
Based on this correspondence, we can deduce which parts of our requirements analysis and modeling are subjective and which parts are objective.
The subjective part:
-
How many domain models are there
-
Which requirement points are met by which domain model
The objective part:
-
Domain models are independent of each other
-
A requirement point is not satisfied by two domain models
Back to Domain Driven Design
If you've read this far following my train of thought and agree with the logic of the previous derivation and the core idea of the previous article in the series, "domain-driven is a value", and that value is "clear boundaries are the most important thing", then you'll be able to see that it's a value that's not just a value, it's a value that's not just a value, it's a value.highlightHere we go, and you'll see that the objective part that we derived earlier is a perfect fit for the domain-driven design values. The subjective part, on the other hand, is not even mentioned in the domain-driven design concepts.
So, going back to the opening statement of the article about being empirical, we believe that the empirical part of software design does not affect the practice of domain-driven design values.
Our central point, then, is that whether or not a decision is consistent with domain-driven design can be objectively judged.Domain-driven design is objectively implementable on the ground and does not rely on human experience。
Doesn't the subjective part matter?
Let's list the parts that are subjective when modeling again:
-
How many domain models are there
-
Which requirement points are met by which domain model
Of course, this part is also very important, the more experience, the more easily and quickly define a more accurate distribution of responsibility model, but it is not as important as the "clear boundaries", because "clear boundaries" to solve the structural problems, while the subjective decision-making part of the solution is "local accuracy problems", which is like the relationship between the "load-bearing walls" and "partition walls" in the building. This is like the relationship between "load-bearing walls" and "partition walls" in a building, where the load-bearing walls determine the overall structure and have a more profound effect on the final result of the building and the cost of future remodeling. The load-bearing walls determine the overall structure and have a more profound impact on the final result of the building and the cost of future remodeling.
(dialect) remarry
To this point, theLao Xiao's path to domain-driven designThe overall logic of this series is nearly closed, and the next installment will analyze the chaos in the software industry from the perspective of "anti-DDD", and what developers can work on.