Guide
The elements in the software do not appear in a vacuum, they are all derived from the actual business. This paper systematically introduces the author's thinking and thinking on modeling from the origin of software design to modeling cases.
1. The inside must be formed outside
Software development engineers are essentially the same as doctors and architects, and they all solve real-world problems, so they all have the same way of doing things. "The Yellow Emperor's Neijing" says that "there are all forms in the inside, and they must be in the outside", which means that if there is something wrong in the human body, it will definitely appear on the surface of the body. For example, we often know that there are wind-heat colds and wind-cold colds, if the cough and spitting is white, it is a wind-cold cold, and if the cough and spitting is yellow, it is a wind-heat cold.
Therefore, you will see that the problems we encounter are divided into appearance and essence, the appearance is what we can see intuitively, and the essence is often not obvious, and it requires in-depth analysis and thinking to deduce. Xiong Jibai, a master of traditional Chinese medicine, summarized the treatment of diseases into two key points: one is the location of the lesion, and the other is the nature of the disease. The lesion site is the specific part of the human body where the problem occurs, and the nature of the disease is wind, cold, heat, dampness, dryness, and fire. Therefore, the key to treatment is to know which part of the body produces the disease because of what, such as cough is caused by cold in the lungs, so the treatment method is to warm the yang and dispel the cold, and promote the lungs to relieve cough. The lesion location and the nature of the disease will be manifested in the appearance of the human body, such as the problem of the nose is more related to the spleen and stomach, and the problem of the eyes is more related to the kidney.
There are many methods of treatment by doctors, such as the dialectic of the Eight Gangs, the dialectic of Sanjiao, the dialectic of Wei Qi and the blood, etc., and the master of traditional Chinese medicine has highly abstracted the origin of the treatment through the lesion location and the nature of the disease, so what is the origin of software design?
Second, the original software design
2.1 Software is the "phase" of the real world
In the two years I have been working in the finance field, I have deeply realized that the elements in the software do not appear in a vacuum, but are derived from the actual business. For example, the income in finance must be generated by a specific business in a certain scenario, and it will never be made out of thin air, so the software world is related to the real world, and the elements in the software must come from the real business.
The essence of software design is to map the "phase" of reality into the software, and to outline the "phase" of reality in the software world (the process of modeling). The "phase" of reality can be expressed in the software, or it can be expressed by the person himself, just like in the field of finance, there is no financial software for financial students can still do accounts, for example, financial students use Excel to do accounts. Whether it is the financial software or the financial students themselves, they all have to understand the "phase" of reality, but one is in the software, and the other is in the brain of the financial students.
Software is like looking in a mirror, mapping reality into a mirror, so what happens in reality, what happens in the software. For example, if we buy a train ticket, before the 12306 website appears, we have to go to the train ticket window to buy it, and after paying the money, the conductor gives us a train ticket, and after the 12306 website appears, after we pay the money on the website, we have an electronic train ticket, the two are not very similar, our behavior in reality is mapped to the operation in the software.
I borrow a concept from the financial field to express that "phase" is a business fact, and business facts are observable through business events, explicit business events are like "outside", implicit business facts are like "inside", and "outside" business facts and "inside" business facts constitute a business model. Whether you perceive it or not, business facts happen objectively, just like you don't study the field of electromagnetic waves, but electromagnetic waves happen all the time, but you don't pay attention to it. Some business facts can be directly observed, such as e-commerce orders to buy goods, and some business facts cannot be directly observed, such as WIFI, WIFI is invisible and intangible, but it exists objectively, so the "phase" has a hierarchical structure.
2.2 Hierarchy of "phases".
"Phase" has a hierarchical structure, and I divide it into two layers: the phenomenal layer and the law layer, and the law layer determines the performance of the phenomenal layer, which is the same principle as the inner must be formed outside the outside. For example, the trading system, the essence is that the platform cooperates with the seller to perform the transaction contract, so in the phenomenon layer, we will see the business facts that there are buyers placing orders, sellers delivering goods, logistics and distribution, buyers receiving goods, and sellers receiving money, while at the bottom level, it is the transaction contract that drives the transaction, which defines the behavior of the platform and the buyer and seller, and drives the transaction process to advance.
The easiest way to perceive the phenomenon layer is to follow the process and you will know what is happening in the whole process, and it is not so simple to gain insight into the law layer. The phenomenal layer is observable, and it is more likely to use the inductive method to continuously converge and summarize the knowledge of business facts, while the regular layer needs to use the deductive method more to define the essence of business facts and diverge outward, and at the same time it can be deduced (because it exists objectively).
Corresponding to the software design, if we only see the business facts at the phenomenon layer, then the designed system is oriented to the functional design of business scenarios and business processes, and the business scenarios and business processes are divergent and diverse, then the versatility and reusability of the system will be relatively poor, and the phenomenon is that the R&D efficiency of business needs cannot be improved, the platform capabilities are constantly iteratively upgraded, and the platform side such as the demand side is scheduled.
I myself have had the experience of doing business systems and platform systems, and I have a deep feeling at this point, I am used to doing business process abstraction when doing platform systems, and ignore the abstraction of the essential business facts of the field, such as business scenarios and business processes are not things that the platform system should pay attention to, and the responsibilities should also be handed over to the development of the business system. A less rigorous method of distinguishing the business facts of the phenomenon layer and the law layer, if the two business facts are the same, it is likely to be the business facts in the phenomenon layer, just like the kernel development and application layer development in the operating system, the two things and levels are different, if the object of processing in the platform is the object in the business system, it can only be said that the abstract level is not enough, and the essential business facts of the domain have not been abstracted. The approach of building a platform towards business process and business model abstraction proved to be a failed approach to platform design.
2.3 Elements of the original software design
As mentioned earlier, the original of software design is to map the "phase" of reality into the software, and the "phase" of reality is outlined in the software world, so what elements should be paid attention to in software design, or how to concretize the original concerns of software design, just like the doctor treats the disease to see the lesion and the nature of the disease.
Business facts are accompanied by business events, that is, a business event appears, corresponding to the occurrence of one or more business facts, for example, the time point of recognition of financial income is the moment when the user signs for it, then the user signs for it is a business event, and the financial income will be subdivided into a variety of incomes, each of which corresponds to a business fact. Business facts do not exist in isolation, they are related to each other, therefore, I summarize the original elements of software design into three parts: look at business events, find business facts, and build fact correlation logic.
Looking at business events is to observe what events have occurred in the business, and the capabilities of all software have to be expressed externally in some way, which is the business event. Business events are directly observable from the upper layers of the iceberg and can be known with just the effort you put in. One of the sentences I appreciate is that "there is no right to speak without investigation", how can you make a judgment without understanding things, looking at business events is in the process of collecting information, laying the foundation for finding business facts and building facts related logic, and a comprehensive understanding of the business is the premise of design.
Business facts are to be found, it is not all concretely displayed in front of us, such as the user orders, we can get an order business facts, it contains the buyer's home, amount, goods, order time and other information, the order business facts at the bottom of the order contract business facts, the closer to the abstraction of the business essence, the more general and flexible the system design, on the contrary, it is based on the phenomenon and process to summarize the unstable system design, just like there are many modes of transactions, such as secured transactions, Timely transactions, etc., a good abstraction should not focus on these. Taking the operating system as an example, it will pay attention to whether the specific application is a video application, a communication application, or a document application, for the operating system, it is a process, so as mentioned earlier, the level of concern for business development and platform development is different, and the business facts handled by the two are also different. The suggested approach is to find out the business facts corresponding to the business scenarios and business processes, make a basic model design, and then diverge the scenario types, consider multiple possibilities, and then see what the constant business facts are, or what business facts play a key role, what problems are being solved by the essence of the domain, and the deeper the understanding of the essence of the domain, the closer it will be to the essence of the business. At the same time, ask yourself whether this is the essential business model, and force yourself to think deeply and explore the essential business facts and business models.
To outline the "phase" of reality in the software world is to build a software model to express the "phase" of reality The process of building a fact association logic is to build a software model, the software model is a final product, the process is to establish the correlation logic between the facts, such as the user has a payment order after the order, there is a correlation between the order and the payment order, and the model is used to express the operation logic of real business facts, which can greatly simplify the cognitive cost of complex problems, and the objects in the subsequent system development are also based on these business fact objects.
3. Modeling cases
You may have heard of different modeling methods before, such as use case modeling, four-color modeling, and event storm modeling, but in fact, the essence is the same, all of which outline the "phase" of reality in the software, but the method of finding the "phase" of reality is different, and the expression is different. And modeling is not just the work of technical students, business, product, testing students can be modeled, modeling can not only simplify the cognition of complex problems, but also reduce the cost of communication, I have met a concept within 3 months different people repeatedly ask what it means, each time to explain, the cost of communication is very high.
In the process of modeling, you will experience the fun of abstraction, the more profound, flexible model, often more abstract, modeling test is whether the objective business facts can be conceptualized and presented, so first observe what the business facts have, and then use the concept to express it, here is a point of view: relationship is structure, structure is model, our essence is to build a model that can reflect the operation of real business, this model contains two aspects, the static aspect is the model structure, and the dynamic aspect is the dependence between each other. Here are some examples of modeling that I've done or seen, and the complexity is progressive.
3.1 Reality mapping abstraction
Every time I talk about modeling, I use it as a case study because it's not only simple, but it represents a shift in design thinking (as opposed to process-oriented design-oriented thinking). The first case is relatively simple, it is the navigation bar of the store, we can intuitively see that a store has a navigation bar, there are multiple navigation tabs in the navigation bar, the number of navigation tabs in different stores is different, and some stores participate in the double 11 promotion, there will be a double 11Tab displayed.
This model is relatively easy to understand, and contains two concepts: the navigation bar and the navigation tab, which are mapped to the real business facts, so we can draw its model.
Although this example is relatively simple, it embodies the most basic modeling idea: what is in reality, what is in the software, back to the original software design, the core work of software design is to restore the business facts, the original appearance of the business facts abstracted. So, you see, I don't think about the process at all, and the process-oriented process artificially regards myself as the "director", and "directs" the whole process, but this process is your self-righteous process, and the work of the process should be implemented in the business layer, and the domain layer will not pay attention to it.
3.2 Ascending the level of abstraction
The second example is Martin Fowler's first example in Analytical Patterns, and the example itself is not complicated, it is an example of modeling an address book, and the model is as follows:
The above model is an abstract model that reflects the real business facts, but it is not enough to reflect the model of the address book, which is now only individuals and companies, and may also be governments, legal entities, etc., so this model does not essentially depict the essence of the address book. Martin Fowler's optimized model is as follows:
There are two conceptual abstractions here, the first is the concept of an actor, and the other is the concept of an organization, which abstracts the previous individuals and companies on top of each other, and then uses the concept of organization instead of the previous company when generalizing the specific subclasses.
Although this example itself is not complicated, it shows us that the model is not a business fact that you see, and that it may also contain other business facts that have not been observed, and that the absence of observations does not mean that they do not exist. Therefore, when modeling, we should think about whether there are other business scenarios, and whether the diversity of the business will have an impact on the business model, so a comprehensive investigation is the basis of the design, or it solves part of the problem (without investigation, there is no right to speak, and practice brings true knowledge).
3.3 Find implicit concepts
The third example, also Martin Fowler's Analytical Patterns, is a slightly more complicated example of the measurement pattern in Chapter 3. Let's first explain the object of quantity, which contains two properties: numerical value and unit, such as 10 kilograms, where 10 is the value and kilograms are the units. The background of this case is that dozens of measurements (height, weight, blood sugar levels, etc.) are collected for each patient in a hospital, at which point the number can be taken as an attribute of the person (equivalent to taking the largest type of measurement), but if the entire medical field is taken into account, then a person may have thousands of possible measurements. Defining a property for each measurement means that there can be thousands of operations on a person, which would form an unrealistically complex interface (dozens of measurements are barely acceptable).
How to solve this problem, Martin Fowler abstracted the concept of measurement, people are included in the measurement of a set of attributes, unlike before to contain thousands of measurement attributes, each measurable thing (height, weight, blood sugar level, etc.) abstracted into a phenomenon type, the phenomenon type is relatively enumerable, the measurement of this object contains two properties: the type of phenomenon and the quantity, as shown in the figure below.
Martin Fowler proposed two modeling principles: one is that the operational layer contains concepts that change daily, and the configuration of knowledge of these concepts is constrained by the knowledge layer and changes much less frequently, and the other is that if a type has many similar associations, abstract these associations into a new type and create a knowledge layer type to distinguish them.
Often implicit concepts are more difficult to excavate, when you don't notice, there will be a lot of repetitive operations in the actual development process, or very complex processing logic, as mentioned above, even if you write 10 or so quantity attributes, it is troublesome enough, when you notice, you will feel very natural, for example, now you look at the measurement of this object is very pleasing to the eye. Another point is that the things that can be enumerated can be abstracted into type concepts, such as Alipay payment and WeChat payment, which can be abstracted into payment methods or payment types.
Fourth, summary
- There are forms on the inside, and they must be on the outside.
- The essence of software design is to map the "phase" of reality into the software, and to outline the "phase" of reality in the software world.
- "Phase" is the business fact, and the business fact is observable through business events.
- The approach of building a platform towards business process and business model abstraction proved to be a failed approach to platform design.
- Without investigation, there is no voice.
- I summarize the original elements of software design into three parts: look at business events, find business facts, and build fact correlation logic.
- Business facts are to be found, and it is not all presented in front of us.
- Modeling tests whether objective business facts can be conceptualized.
- Relationships are structures, and structures are models.
- What is in reality, there is in the software.
- The core work of software design is to restore the business facts and abstract the original appearance of the business facts.
Author: Bu Pull
Source-WeChat public account: Alibaba Cloud Developer
Source: https://mp.weixin.qq.com/s/_pD-TTj-Lj68S4PsWVNlLA