Modeling Method (3) Model Evolution-three suggestions for maintaining simplicity and elasticity

Q: "For programmers who develop information systems, what are the most disturbing, hot, uneasy, tangled, and hard-to-do tasks and will be complained about ?"
The answer is "Building a domain model ". A good (or reasonable) model must be based on a deep understanding of the business. A programmer who has just been familiar with a strange field, no matter how hard he works, must have a superficial and one-sided understanding of the business. He knew that the model he made at this time was not reasonable enough, but he had to do it again. It could be said that he knew that he could not do it for him. How could he not be confused, angry, or uneasy? With the development of the project, the understanding of the business is also deepening, and the model needs to be constantly reconstructed-the same is true for "DDD", but it does not mention the reconstruction cost. The irony is that the more you get to the final stage of the project, or even after a while, the more likely you get to "Aha! This is the case !" Epiphany. If you have already completed 100 pages and 300 reports, and millions of production data records with a penny, even if you transfer a field from one table to another, it may take you days to get upset. Reconstruction or not? How can you not be entangled or complained?

Simple

Reconstruction is inevitable, especially when the project is productized and its life cycle is 5, 10, or longer. Now that we know that the initial model is definitely not reasonable enough-just bite your teeth and admit it-our goal can only (very grievance) be to "build a model with a low reconstruction cost ".
What kind of model is that? The answer is also common: "simple model ".

Modeling Method 4The initial model must be simple.

Everything is always from small to big, from simple to complex, so you may say in your mind, "This article is a nonsense ." The problem here is that we know that the reconstruction cost of the domain model is very high, and there is a lingering worry about this. Even if we think, "in the current situation, one employee has only one department ......", However, there is always a little devil whispering in his ear: "With regard to past experience and customer complaints, it is very likely and reasonable for an employee to have multiple departments, rather than restructuring them in the future, it is better to design multiple-to-many relationships now ......"

After a while, there was a need: a doctor was originally in a certain Inpatient Department (for example, one ward, two wards ......), But he also needs to go out of the clinic from three different places. When he leaves the clinic, he belongs to an outpatient department (such as general clinic and pediatric clinic ......). Is our forward-looking design successful ?! After careful investigation, we will find two problems: 1) Although a doctor can have multiple departments and roles, he cannot be both a resident doctor and an outpatient doctor at the same time; 2) when he is working in the inpatient department, not only does his department belong to a certain inpatient department, but also the functional modules required are different from those of the outpatient department. That is to say, a doctor has two identities: "resident doctor" and "outpatient doctor", which correspond to different departments and roles. When working, he must select an identity as his current identity.

In actual implementation, considering that "most employees only have one identity" and "employees have up to three identities", we can use a simpler structure:

If an employee does not have a second department or a second role, the employee is empty. If an employee has a second department and a second role, You must select a department and role as the current department and role when logging on to the system.
TipsWhen analyzing services, you must distinguish between "limited multiple" and "uncertain number of". They often need different structures.
It is not difficult to draw a conclusion from the discussion,It is not easy to re-construct a complex model with a simple model. However, if a complex model is used at the beginning, it is often necessary to reconstruct a complex model to another complex model, that's a little daunting..

Concept

Because the reconstruction cost of the model is relatively large, it is still expected that the model should not be changed. However, the new requirements are unpredictable. At the same time, due to the reasons discussed above, we do not want to do too much proactive design. How can we increase the elasticity of the model? Why are the well-designed models always able to cope with changes in demand? If you want to say anything, it's --

Modeling Method 5Focus on concepts behind physical objects from the very beginning

I don't want to be confused. HereConceptIt refers to a little bit of physical objects.Abstraction, Consider itsNature.AbstractionThis means that we ignore unimportant attributes and focus on the value and significance of these attributes to customers and systems.NatureIt refers to the inherent things that are not easy to change. For example, a person's character is not easy to change, so he can grasp Sima Yi's suspicious character, and he can probably expect an empty city plan to make him dare not attack the city. Similarly, if you can grasp the value and meaning of each object in the business to the customer or system and see which part is inherent and not easy to change, then, in the opinion of outsiders, you probably have the knowledge of the enemy first.
It's easy to say, but there are still several problems to do it. 1) when and where should I start? 2) what is important and what is essential? The benevolent sees benevolence, and it is difficult to find the basis and standard of judgment. 3) Abstract A thing, there are countless directions and layers. As the story tells us, the great ox named Wang shouren in the Ming Dynasty decided to become a sage when he was young, so he decided to practice the "thing-based knowledge" of the Sage of Zhu Da ", every day, the bamboo in its own backyard has been staring at the bamboo, regardless of the wind and rain. Later, bamboo failed to catch a cold.
The following two questions cannot be considered. They are probably in the category of "art. There is a good suggestion for the first question-when you encounterConflictIs a good opportunity.
Let's look at a specific example. If you go to the hospital to see the disease, you must be familiar with the pile of receipts you get after paying the fee. Of course, we generally don't take a closer look at them. When we get to the doctor, we will give them all a bunch of receipts, and then we will carry the rest in our pockets. So now let the experts in the field tell us something.
"This kind of receipt is generally '3-connected', that is, three sheets of paper in the same size and format are stacked together, and the copy function is available between sheets, after being printed by the dot matrix printer, three sheets of paper have exactly the same content. These three sheets of paper are called the root contact and are kept by the cashier; the second is called the notification contact, and the Execution Department (that is, the department responsible for executing the doctor's advice, such as the radiation room, laboratory, outpatient and pharmaceutical Bureau), so this association is also called the execution Association; the third is the reimbursement credential, which is kept by the patient.
"Each receipt has a receipt number, which is printed one by one consecutively. For non-medicinal advice, each doctor's advice has a receipt; for medical advice, each prescription (a prescription may contain 1 ~ 5 drugs) a receipt. The main content printed on the receipt is the doctor's name, quantity, amount, and total amount of the entire receipt.
"Note that the above is a rule for self-paid patients. For medical insurance patients, the total cost of all medical orders is printed on the first receipt, and the receipt is indicated as the "Medical Insurance Federation receipt", which is specially used for reimbursement; then print the execution contact. The rule is that each non-medical doctor has an execution contact and each prescription has an execution contact. Because the execution link is printed on the receipt paper, you must also specify the words "this is the execution link and cannot be used for reimbursement ......" After the field experts said, they gave programmers a little bit of satisfaction.
"I'm confused, this is a mess ......" The programmer heard that this was almost a crash. "Not only are the treatment methods of medical doctor's advice different from those of medical doctor's advice, but the treatment methods of self-paid patients and medical insurance patients are much different. How can this problem be solved ?"
To be honest, the model becomes bloated and hard to understand, thanks to various "other situations. However, these are the actual services that are happening every day. If we say "there is a reason for existence", if we can understand these reasons, it will become a good opportunity to deepen our understanding.
Where can I start? Starting from the most obvious inconsistency: we can find that for self-paid patients, the receipt is exactly the same as the execution Link (because the three links are printed at a time, for medical insurance patients, the receipt and execution are separated, and the ticket number and content are different. This implies that our receipt and execution association may be two different concepts.
From the value and significance of the existence, the role of the receipt is 1) as proof that the patient has been paid; 2) basis for reimbursement. 1) indicates that the patient has paid for the doctor's advice; 2) indicates which doctor's advice should be performed by the executive department of the hospital.
Abstract: From the Perspective of topology, we can think that both receipt and execution are groups of medical orders (corresponding billing items), but the grouping methods are not necessarily the same. An important question is whether these two grouping methods are bound?
Let's look back at the rules and see how many non-essential factors there are. Of course, as discussed above, is it subjective and relative in nature. It can be considered that "X-ray examination and blood test should not be printed on the same execution link" is essential because these two medical orders need to be executed in different executive departments, if it is hit on an execution link, can it be difficult to split the execution link into two pieces? However, the reason why "one executive contact for every non-medical doctor" is clear is that programmers want to be lazy-judging which medical orders belong to the same executive department is a little troublesome. If too many medical orders need to be considered, a small ticket may not be enough, in addition, this will make refund easier (refund is another complicated topic, which will not be discussed in this article ). "For Medical Insurance patients, the total cost of all medical orders is printed on the first receipt." It may be because the medical insurance center requires this, it may also be technically difficult to settle medical insurance in several groups.
After some analysis, it is not difficult to draw a conclusion. It is essential to print the doctor's orders (corresponding expense details) to the bills (receipts and executions) in groups (of course, as the hospital and the whole society become more and more paperless in the future, these bills will gradually disappear ). The grouping rules for the two types of tickets may be identical or quite different, depending on technical restrictions or implementation convenience, and there is no necessary link between them.

When creating a ticket, we provide two grouping algorithms: GroupMethod1-for non-medicinal orders, one group for each doctor's advice; for medical orders, one group for each prescription; groupMethod2 -- a group of all doctor orders. For self-paid patients, use GroupMethod1 to create a receipt and execution Association; for medical patients, use GroupMethod2 to create a receipt and use GroupMethod1 to create an execution Association. When the bill is printed, the self-paid patient only prints the receipt; the medical insurance patient prints the receipt first, and then prints the execution Association.
Because the attributes of the receipt and the execution link are almost the same, you can also use the receipt and execution together with an entity named "bill" to represent the actual implementation. In addition, because the receipts of common patients and all attributes of the execution Association are the same, the persistence of the two almost identical data does not seem to mean much. At the moment, we can not create an execution Association for Self-paid patients. As for whether to use subclass or get a factory or something, you can make a decision based on the actual situation. This article will not be discussed in detail, but at least the two grouping algorithms and the Code for creating tickets should be encapsulated into functions.

Outside of the Model

Let's talk a little more about the problem. When the customer asks us to implement complicated functions, be careful-it may be that the customer's head is hot and there is no simpler and clearer solution to the problem. At this time, even if we can assume that the development team has a high level and can quickly and effectively develop the program, we still have to face two problems: 1) The program is too complicated, it is very difficult to prove to the customer that the program is glorious, great, and correct. It takes a long time for the customer to trust the program, which indicates greater training and maintenance costs; 2) customers may not be as intelligent as programmers, especially when they need to collaborate with numerous users who have different basic and different interests in multiple departments-they do not understand complicated and subtle programs, finally, we can only use the simplest part-the programmer should be aware of the boundaries of Program Complexity and feel that "this is going to be broken ". At this time, if the programmer can give a simpler method, the customer will thank you for achieving a win-win result. This can also be said to be "outside the model ". I believe that in the future, the development of enterprise management software will be carried out together with the management consulting, from the current business-driven development to information construction to promote management improvement.

Modeling Method 6Helps customers find simple and effective solutions.

This article requires programmers to think about the nature of the business at a higher level. Intuitively, it may be irrelevant to the program, or at least the programmer is not the best candidate, but I don't think so. There is a saying: "If you want to know whether you really understand it, use a program to implement it." If the programmer has successfully created an information system to simulate real business, his understanding of the business must be more profound and comprehensive than that of ordinary business personnel. In addition, he is so intelligent. If he is willing to go further, who can block it?