The author | jian-fei zhang Alibaba senior technical experts

We often use if-else to implement different business logic in different scenarios. As time passes, the code becomes more and more difficult to maintain. So how do I get rid of these if-else? How to think and analyze complex business? This paper shares the methodology of Complex business governance by Frank Zhang, a senior technical expert of Alibaba, and introduces a multi-dimensional analysis method: matrix analysis.

You should not be an if-else coder, should be a conquer. — Frank

This article is a response to my previous post on Ali Senior Technical Expert Methodology: How to Write complex Business code? Said “top-down structural decomposition + bottom-up abstract modeling” methodology upgrade. In the previous methodology, we lacked a multi-dimensional perspective. This lack of dimensional thinking may lead to the miss of some important business information, which makes it difficult for us to make software design strategies.

With dimensional thinking, we can see the whole picture of the business more comprehensively and master the business information more comprehensively, thus helping us to deal with complexity in a more systematic way.

From the if – else

I always say, let’s not do an if-else coder. If-else here does not mean that we cannot use if-else in coding, but that we should not use if-else to achieve branch flow of business, because such arbitrary code stacking is easy to pile up a pile of “shit mountain”.

Business differences are at the root of if-else. Take retail Link’s commodity business as an example. Different processing scenarios have different business logic implementations. As shown in the figure below, the differences in commodity businesses are mainly reflected in different commodity types, sales methods and storage methods.

The difference between these three dimensions is as much as 2 * 3 * 2 = 12. That’s why, in old code, you see if blabla, if blabla, if blabla, and so on.

So, how do you get rid of those pesky if-else? We can consider the following two ways:

• Polymorphic extension: the use of object-oriented polymorphic characteristics, code reuse and extension.

• Code separation: Use different process code implementations for different scenarios. This is clear, but not maintainable.

1. Polymorphic extension

Polymorphic extensions can be inherited or combined. Not to mention inheritance, composition is a bit like a strategy pattern, which is to encapsulate and abstract the parts that need to be extended into objects that need to be combined, and then extend them. For example, the ability of star rings is extended in this way.

Here, we take an example of inheritance. When a product is put on the shelf, it is necessary to check whether the state of the product is available for sale. The general Item can check itself, while the CombineItem needs to check each sub-item.

Using procedural coding, it is easy to write code like this:

public void checkSellable(Item item){ if (item.isNormal()){ item.isSellable(); } else{List<Item> childItems = getChildItems(); childItems.forEach(childItem -> childItem.isSellable()); // omit exception handler}}Copy the code

However, this implementation is not elegant, does not satisfy OCP, and lacks explicit expression of business semantics. Better, we can explicitly express the relationship between CombineItem and Item through the model.

This way, on the one hand, the model correctly reflects the entity relationship, and is clearer. On the other hand, we can use polymorphism to deal with the differences between CombineItem and Item for better scalability. After refactoring, the code becomes:

public void checkSellable(Item item){ if (! Item.issellable ()){throw new BizException(" The state of the item is unsellable and cannot be sold "); }}Copy the code

2. Code separation

Code separation means that for different business scenarios, we separate them with different choreography code. For example, we can write:

*/ public void itemOnSale(){checkItemStock(); // Check inventory checkItemSellable(); // Check the sellable status checkItemPurchaseLimit(); // Check limit checkItemFreight(); // Check the freight checkItemCommission(); / / check the commission checkItemActivityConflict (); GenerateCspuGroupNo (); // Generate item group number publishItem(); */ public void combineItemOnSale(){checkCombineItemStock(); // Check inventory checkCombineItemSellable(); / / check the available state checkCombineItemPurchaseLimit (); CheckCombineItemFreight (); / / check freight checkCombineItemCommission (); / / check the commission checkCombineItemActivityConflict (); GenerateCspuGroupNo (); // Generate item group number publishCombineItem(); */ public void giftItemOnSale(){checkGiftItemSellable(); // Check saleable status publishGiftItem(); // Publish goods}Copy the code

This way, of course, you can eliminate if-else, independent of each other, and still be clear. But reusability is a problem.

3. Multidimensional analysis

If you are careful, you may have noticed that in the above case, the business process for ordinary goods and composite goods is basically the same. If you use two sets of choreographed code, which is a bit redundant, this duplication will not be conducive to the maintenance of the later code, resulting in the problem of scattershot changes (multiple changes to the same business logic).

In one extreme case, if the checkSellable() is different from the checkSellable() of a generic commodity and a composite commodity, everything else is the same. No doubt it would be more appropriate for us to use polymorphic combineItems and items to handle differences.

On the contrary, the presentation process is very different from that of other products. It’s not a good idea to share a set of process code with them, because it adds to the cost of understanding. It is better to have a separate process that is clear.

So, the question is, when do we use polymorphism to deal with differences, and when do we use code separation to deal with differences?

Next, one of the methodologies of multidimensional analysis that I’m going to focus on for you today is matrix analysis.

We can make a matrix, the vertical column represents the business scenario, the horizontal column represents the business action, the content inside represents the detailed business process of the business action in this business scenario. For our commodity business, we can get the following matrix:

Through the above matrix analysis, it is not difficult to see that common products and composite products can reuse the same set of process orchestration code, while the business of gifts and cleaning products is relatively simple, which is more suitable for a set of independent orchestration code, so that the code structure will be easier to understand.

Dimensions of thinking

1. The importance of multiple dimensions

The above example is not made up by me, but is a true story of my discussion with Zhang Wen (my colleague) about how business differences should be handled.

I remember driving back from a discussion with the university, thinking about this, and then I was at a red light at the second intersection when I had an Epiphany. Unable to contain my excitement, I texted Zhang Wen while driving: “I have an excellent methodology to solve the problem of choosing between ‘polymorphic extension’ and ‘code separation’.”

In fact, I know I’m excited about more than just solving the problem. I was excited that for the first time I really understood the importance of multi-dimensional thinking. The opportunity to upgrade from a unidimensional creature to a multidimensional thinker. Mom doesn’t have to worry about me being hit by dimension reduction anymore 🙂

Structured thinking is useful, very useful, very useful, but it focuses more on one dimensional things. I have to break down the business process, I have to break down the work schedule my boss gave me, I have to comb through the test cases, it’s all one-way.

Complexity, on the other hand, is usually not just complexity in one dimension, but complexity across multiple dimensions. When there are many elements involved in the problem and the relationship between them is very complex, two dimensions will definitely be clearer than one dimension, which is why matrix thinking is a higher level of thinking than structured thinking.

In fact, it is not difficult to see from the Chinese vocabulary that a person’s thinking level is positively correlated with his thinking dimension. When we say that this person is “axial” and “single-minded,” what we are really saying is that he has only one dimension of linear thinking. Therefore, the more perspectives to observe things, the richer the dimensions, and the higher the level of thinking.

2. Omnipresent multidimensional thinking

With these insights, I began to systematically sort out the data about multi-dimensional thinking and analysis, and found that this way of thinking is really everywhere. The more I discovered, the more I wondered why such an important way of thinking had only now dawned on me.

1) Boston matrix

For example, when doing product analysis, there is a Boston matrix for analyzing product prospects.

2) Analysis of order elements

At that time, when I placed an order in 1688, there were a lot of ordering scenarios. In each scenario, the rights and interests of buyers were different (as shown in the following table). We also used matrices to express this complex relationship, but we didn’t think of elevating it to the level of methodology.

3) Data cross analysis

In data analysis, dimensional analysis is very important, especially when there are many dimensions, we can do cross analysis through Pearson product moment correlation coefficient, so as to make up for some problems that cannot be found by independent dimensional analysis.

Simple correlation coefficient matrix

4) Analysis matrix

I recently came across a book called Design Pattern Analysis by Alan Shalloway. Design Patterns Explained, a classic book on OOP, has chapter 16 devoted to “Analysis matrices”. The author created this methodology because there are too many elements involved in business, and he needed a new way to organize massive amounts of data.

Alan and I took different paths, but we both came to the same conclusion. It can be seen that this matrix analysis method is indeed a powerful tool for analyzing complex business. The more business scenarios and the more complex the cross-relations, the more necessary such analysis is.

5) Formation

Production relations determine productivity. For a manager, how to set up the organizational structure effectively is the key to determine whether the team can cooperate efficiently. Therefore, we can see that in the company, there is a big adjustment of organizational structure and personnel arrangement every year.

For technical teams, we are used to dividing the scope of work by domain. The benefit of this is that responsibility is personal and clear. However, the domain is only one dimension, and our work is usually carried out in the form of projects, which often span multiple domains. Therefore, when making team organization planning, we can look at it from two dimensions: business field and business project.

For example, in the commodity team I am in charge of, I will divide responsibilities according to the following form.

6) Time dimension

In addition to work, the importance of multi-dimensional thinking can be seen everywhere in life.

For example, we say that it is shameful to waste, and we should lick the plate very clean. However, after adding the time dimension, your current licking plate may cost more resources and energy to lose weight in the future, but it will cause more waste.

We say code is ugly because of the need to support the business “quickly”, adding the dimension of time to this temporary compromise, in return for unexpected bugs, online glitches, and endless 996.

7) RFM model

Simple thinking is in the form of “points”, such as licking the plate and stacking code. A better way to think is “line”. With a time line, it is not hard to see that “point” is problematic. A more comprehensive thought is “surface” (two-dimensional); A more systematic way of thinking is “body” (three-dimensional); For example, the RFM model is a good 3D model. Unfortunately, in terms of expression, we humans can only simulate three dimensions in two dimensions, otherwise four dimensions might be more useful.

Summary of complex business Governance

As I said in the introduction, multidimensional analysis is an update on previous methodologies. With the previous methodology, the complete methodology would be “Business understanding -> domain modeling -> process decomposition -> Multidimensional analysis”.

To facilitate your understanding, let me make a simple series and explanation of these methodologies.

1. Business understanding

Understanding the business is the starting point of all work. First, we need to find the core elements of the business, understand the core concepts, and comb through the business process.

For example, in the retail goods domain, we need to know what is an Item, what is a CSPU, and what is a CombineItem. In the order field, we know that the elements of an order are goods, offers, and payments. In CRM, we need to understand customers, opportunities, contacts, Leads, and so on.

Here, I would like to emphasize once again the importance of language. Language is the carrier of our thinking. As Wittgenstein said, “Everything that can be said can be said clearly”.

You shouldn’t let go of any vague business concept, it’s important to understand it thoroughly and name it ubiquitously. Only in this way can we understand the business more clearly and carry out the follow-up work better.

2. Domain modeling

In software design, models refer to entities and the relationships between them, which requires good abstraction. Able to find the essence of the business through the complex appearance.

The core concepts should not be too complex, no matter how complex the business area is. If we get to the core, we get to the main line, and the business is often built around these core entities.

For example, the commodity domain is complex, but its core domain model looks like this:

3. Process decomposition

On process decomposition, ali Senior Technical Expert Methodology: How to Write Complex Business Code? There has been a very detailed elaboration, here is not repeated.

In simple terms, process decomposition is the detailed decomposition of business processes, using a structured methodology (deductive, then inductive), and finally forming a pyramid structure.

For example, in the field of goods, there are a series of actions (processes), such as creating goods, putting goods on the shelf, checking goods on the shelf, checking goods off the shelf, modifying goods, deleting goods, etc. Behind each action there are very complex business logic. We need to comb through these processes in detail and then break them down step by step. Finally, a pyramid structure is formed as follows:

4. Multidimensional analysis

As for multidimensional analysis, LET me take two-dimensional matrix analysis as an example, which I think I made clear earlier.

The complexity of business is mainly reflected in the complexity of process and the correlation and dependence of multi-dimensional elements. Structured thinking can help us sort out process, while matrix thinking can help us sort out and present multi-dimensional correlation and dependence. The combination of the two can show the whole picture of complex business more comprehensively. So that our governance can be targeted, rules to follow.

Since it is a methodology, I will try to give a framework of matrix analysis here. Imagine if our business was simple, with only one business scenario and no branching processes. Our system won’t be too complicated. It is complicated because various business scenarios overlap, depend on, and influence each other.

Therefore, when we were doing the matrix analysis, the vertical axis can choose to use the business scenario, the horizontal axis is alternate dimensions, can be affected by the scene of the business process (e.g., the commodity flow matrix graph) in the article, also can be affected by the scene business attribute (such as the order component matrix chart) in the article, or any other “stuff” of different nature.

The matrix shows service differences in different scenarios. Based on this, we can customize the best implementation strategy to satisfy the differences, whether it’s polymorphic extensions, separate code, or something else.

This is the essence of matrix analysis, its essence is a multi-dimensional thinking methodology.

Following remarks

Finally, I’d like to say that the world is entropic (that is, everything is slowly falling apart) and that it is our responsibility and mission to control complexity.

The development of software industry is only a few decades, is still a young discipline, software engineering is like a toddler, is still very immature, sometimes very naive.

But after all, there are still decades of precipitation, there are still some good methods and practices to refer to, my summary of precipitation is just on the basis of predecessors, a little bit more. But this is a little bit, it is not easy to come from, among them, only their own can experience. It can be said that along the way, it is a continuous test of heart, brain and physical strength.

• Heart is an unyielding ingenuity, an uncompromising determination, an insatiable curiosity, and an unyielding perseverance.

• Brain power refers to the necessary ability to think, to learn, to think, to think.

• The reason “business understanding -> domain modeling -> process decomposition -> multidimensional analysis” is hard work is because implementing them is like filling in the blanks, no matter how complex the business is, it can become clear step by step if you are willing to take the time.

With a clear picture and COLA’s (start.aliyun.com/) guide, it’s possible to write clean, easy-to-read code and upgrade from an If-else coder to a full complexity conquer.

And isn’t that what our engineers are pursuing tirelessly?

“Alibaba Cloud originator focuses on micro-service, Serverless, container, Service Mesh and other technical fields, focuses on the trend of cloud native popular technology, large-scale implementation of cloud native practice, and becomes the public account that most understands cloud native developers.”