This book picks up where the previous one left off, "That's Why You Can't Learn 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.
/s/TJEtclwcJydiE58pjWpXXw
contexts
As I said before, we have to let go of the burden of technical aspects of the mind when modeling, which is relatively easy to overcome as it is an internal problem of our own. But on the other side, when we analyze the requirements and design the model, we will have in-depth communication and interaction with business people, product managers and other roles, and at this time, it is difficult to find a more consistent way of presentation in order to show in everyone's brain a relativelycoherent imageThe efficiency and accuracy of communication is very poor, as there are often cognitive biases and even situations where people arrive at opposite understandings of each other without being able to detect them.
To solve this problem, we found a very acceptable "analogies", that is."Anthropomorphic modeling communication method”。
PS: You still have to forget all your technical knowledge first.
Why anthropomorphism is possible
Let's start with the diagram below, showing the organizational structure of a company:
If we leave the structure of the diagram unchanged and simply replace the names of the elements, we get a structural diagram of the system:
Here we get the followinga correspondence：
Where the company corresponds to the system and the department corresponds to the module, which can be interpreted as a hierarchy or grouping, is more natural, next we focus on why employees and models can correspond.
Commonalities between "people" and "models"
First of all, let's think about how employees collaborate with each other in an organization, and I think it's nothing more than the following two scenarios:
- It's a real "hands on" approach;
- I'll do my part and let you know. You do yours;
Similar to the picture below:
If a task requires Employee A to teach Employee B to do it by hand, doesn't that mean the following:
- Employee B is unable to complete the task independently;
- Employee A is ultimately responsible for the task, or at least AB is jointly responsible;
If two employees have a collaborative model mode 2, i.e., "I do my thing, then inform you, and you do your thing," doesn't that mean:
- Employee A and Employee B each have their own responsibilities;
- Employee A and Employee B collaborate through Notifications (Events);
Based on the above logic, can't we draw the following analogy:
Based on this analogy, we can conclude the following:
- If a task requires model A to directly depend on (invoke) model B, it means that they cannot accomplish the task alone;
- If Model A and Model B collaborate only through events, this indicates that they are independent of each other and have clear boundaries of responsibility;
This conclusion scenario 2 is very reasonable, but if we encounter scenario 1, where a task requires a common information collaboration between model A and model B in order to be accomplished, we generally consider that there are two alternative scenarios:
- Merging Model A and Model B, viewing them as a whole, is represented on the model diagram by the fact that they are connected by solid lines and they are an aggregated whole;
- Model C is created to take care of the resolution of this task, with Model A and Model B telling the information to Model C through event notifications;
Ultimately, our models will be collaborating through events, and the commonalities between "people" and "models" are roughly as follows:
- Both "people" and "models" have their own roles and are responsible for solving specific business problems;
- Both the "person" and the "model" have the information they need to fulfill their roles;
- Both "people" and "models" collaborate through event-driven;
Anthropomorphic modeling communication method
Based on the above derivation, we can think of each "model" as a personal name, and then when we communicate, we can use anthropomorphic ways to express business processes, the responsibilities of the model, what information the model needs to carry, and the commands and events:
- When the "Payment Order" is successfully paid, the "Order" has to set its payment status to Paid;
- When a "user" registers successfully, 5 points are sent to the "user points account";
- The "product list" should display "product information" and "sales statistics" of the integrated information, but also to support a variety of latitude of the search, the performance must also keep up;
Through anthropomorphization, we can build consistent images in the brains of business people, product managers and technicians, which correspond to "responsibilities", "capabilities" and "boundaries", so that we can deduce the definition and division of labor of these "models" on one channel. These images correspond to "responsibilities", "capabilities" and "boundaries", so that we can deduce the definition of these "models" and the division of labor in a channel, whether it can really meet the needs, so our team has gained a capability, that is, "effective modeling communication", and we can achieve the goal of "effective modeling communication" by using this capability. With this ability, we can realize the first half of the consistency of "requirement-model-code", i.e. the consistency of "requirement-model":
(dialect) remarry
Stay tuned for more on how to maintain model-code consistency.
Please follow the public number (Old Shaw wants to be a foreign language big brother) for the latest updates.