Remove unnecessary design concepts

The software design should first organize the user's business model, and then use this as a reference to establish a Software System Model Based on environmental conditions. In this process, it is important to remove unnecessary concepts in the software model.

What are "redundant concepts? If a concept cannot be directly observed in the user's business model, but is obtained by the designer, then this concept is redundant.

We imagine a railway company running a route between four cities in ABCD. The locations of these cities are as follows:

The boss of the railway company wanted to build a ticket sales system. He found a software company. Assume that I am working in this software company as the project owner. The boss of the railway company said to me: the fare from A to B is 50 yuan, the fare from B to C is 60 yuan, and the fare from C to D is 30 yuan, as follows:

On this basis, the fare between two cities is the sum of each section. For example, the fare from A to C is AB + BC, or 110 yuan.

So I went back to the office and started to design the system. I think: this system is very simple. It uses City A as the starting point to record the fare between City A and each city. Just like this, I designed a data table to save the fare. It is like this:

SQL> SELECT * FROM TICKET_PRICE;

CITY PRICE
---------------
A 0
B 50
C 110
D 140

When a passenger buys a ticket from B to C, we will use C's fare to subtract B's fare, get the fare from B to C, and get 60 yuan. If you want to get from D to B, you can use D's fare to subtract B's fare and get 90 yuan.

This design is very concise and looks no problem. According to this idea, we started to write code. However, soon I was in trouble.

The boss of the railway company called and said: we are making some adjustments to the fare. The fare from A to B is kept at 50 yuan, and the fare from B to C is kept at 60 yuan, however, the fare from A to C is now adjusted to 100 yuan. In addition, the fare from C to A should be off, that is, 80 yuan.

The problem is that the TICKET_PRICE table is subject to major changes and all the business logic based on this table needs to be changed.

What are the sources of troubles? The reason is that this design is based on one of my inferences, rather than the business facts that can be directly observed. The business fact is that the fare between A and B is 50 yuan, the fare between B and C is 60 yuan, and the fare between A and C is 110 yuan ...... On this basis, I made an assumption that the fare between A and C is AB + BC. Of course, I make this wrong assumption that some of the bosses of the railway company have "credit ". In any case, the change is inevitable. The railway company and I must bear the consequences of this mistake. The railway company needs to invest in additional projects, and our development costs will rise. On my own, we must work overtime.

There is A redundant concept in this design: City A is A benchmark. This is a concept that cannot be directly observed in the business process, And I mistakenly use it as the basis of the entire system, let the prices between all cities be based on their fare to City.

What can be directly observed from the business? There is only a fare between two cities. When A passenger arrives at the railway company to buy A ticket, the price from A to B is 50 yuan, and the price from B to D is 90 Yuan ...... He can only observe this, but not A city as A benchmark. The system design should be based on a solid business foundation, rather than any inferences. The concept of "benchmark" needs to be removed from the design.

Re-design the system to describe the fare between cities in the following form:

	A	B	C	D
A	0	50	110	140
B	50	0	60	90
C	110	60	0	30
D	140	90	30	0

Of course, I can use such a data table to store such fares:

SQL> SELECT * FROM TICKET_PRICE;

START DESTINATION PRICE
---------------------------------
A B 50
B A 50
A c 110
A 110
B C 60
......

If I did this at the beginning, I would feel more comfortable after receiving a call from the railway company.