Source of software degradation

The development of the Internet in the last 10 years, from e-commerce to mobile Internet, and then to the Internet transformation of “Internet +” and traditional industries, is a very painful transformation process. The development of artificial intelligence and 5g technology in recent years will drive the whole industry to develop towards big data and Internet of things. Another round of technological transformation has begun.

In this process, on the one hand, it will bring us many challenges, and on the other hand, it will bring us endless opportunities. It will bring more emerging markets, emerging industries and new businesses, and bring us new development opportunities.
However, in the face of new business and new growth points, can we seize this opportunity? We hope to grasp it, but every time we return to the reality and the system under maintenance, it is frustrating. Our software always goes through this cycle. When the software design quality is the highest, it is the version designed for the first time. When the design of the first version is launched, various requirements are changed, which often disrupts the original design.

Therefore, once the requirements are changed, the software is modified once, and once the software is modified, the quality is reduced once. No matter how high the design quality of the first time is, the software will enter a state of low quality and difficult to maintain after several changes. In addition, the team has to maintain continuously for many years at high cost in such a state.
At this time, it is very difficult to maintain the original business. How can we expect more new business in the future?

Here comes the question: why is the software degraded and the design quality degraded with changes? On this issue, we must find the root cause of the problem before we can prescribe the right medicine and solve the problem.

To explore the root cause of software degradation, we should first explore the essence and laws of software. The essence of software is the simulation of the real world. Every software can find its shadow in the real world. Therefore, the only criterion for the correctness of business logic in software is whether it is consistent with the real world. If so, the software is OK; If not, the user will raise bugs and new requirements.

A very important clue has been found here, that is, what kind of software should be made is not decided by us or users, but by the objective world. The reason why users always change their needs is that they are not sure about the rules of the objective world. Only when they encounter problems can they remember. Therefore, for us, it is better to analyze the software on the basis of understanding the business than to do the software according to the user’s requirements, which will help us reduce the cost of change.

So, it’s easy for us to develop software according to the real world? In fact, this is not the case, because the real world is very complex. It takes a process to deeply understand these business logic in the real world. Therefore, we can only recognize those simple, clear and easy to understand business logic in the real world at first, and put them into our software, that is, the requirements of the first version of each software are always clear and easy to design.

However, when we deliver the first version of the software to the user, the user will find that there are many business logic that is not simple, unclear and easy to understand. This is very inconvenient in the process of using the software and inconsistent with the real business. Therefore, users will raise bugs and new requirements.

In the process of constantly repairing bugs and realizing new requirements, the business logic of the software will become more and more close to the real world, making our software more professional and making users feel better and better. However, in the process of software getting closer to the real world, the business logic will become more and more complex and the software scale will become larger and larger.

Maintaining software quality: Domain Driven
As mentioned earlier, the essence of software is the simulation of the real world. Therefore, we will have an idea whether we can match the software design with the real world. What the real world looks like, then how the software world is designed. If this is the case, each time the requirements are changed, restore the changes to the real world, see what the real world looks like, and make changes according to the real world. In this way, no matter how many changes are made and how many rounds of changes are made in the future, the design will be carried out according to this method, so that the direction will not be lost and the design quality can be guaranteed. This is the idea of “Domain Driven Design”.

So, how to match the real world with the software world? Such correspondence includes the following three aspects:
What there are in the real world, there are objects in the software world;
What are the behaviors of these things in the real world, and what are the methods of these objects in the software world;
What are the relationships between these things in the real world? What are the relationships between these objects in the software world.

In domain driven design, the above three correspondences are first made into a domain model, and then the program design is guided by the domain model; Every time the requirements are changed, the requirements are first restored to the domain model for analysis, and the changes are made according to the real world behind the domain model. Then, the software changes are guided according to the changes of the domain model, and the design quality can be improved.

In short, the law of software development is to gradually change from simple software to complex software. Simple software has the design of simple software, and complex software has the design of complex software. Therefore, when the software changes from simple software to complex software, it needs to adjust the program structure timely through two hats, and then realize new requirements. Only in this way can the software not be degraded. However, how to adjust the code to meet the new requirements when changing?

DDD gives us ideas: when making changes, we should first return to the domain model and change the domain model based on the business. Then, based on the change of the domain model, guide the change of the program. In this way, no matter how many requirements changes are experienced, the design quality can always be maintained. Such a design can ensure that the system can be maintained continuously at low cost.