复杂性应业务抽象本质——系统化多维度思考（如何让抽象更上一层楼）

小咪咪 2022-12-11 05:25 201阅读 0赞

![d9b741ec3eae9360bfff76f94ba77e05.png][]

# **前言** #

这篇文章，是对之前我在[《资深技术专家推荐：如何写复杂业务代码-阿里实践》][-]说的“自上而下的结构化分解 + 自下而上的抽象建模”方法论的升级。因为在之前的方法论中，我们缺少一个自顶向下多层次和多维度看问题的全局视角，导致可能会miss掉一些重要的业务信息，从而在制定设计策略的时候，陷入困难。对于企业业务单元来说，从抽象的角度来讲，大部分的业务具有相似的业务流程和相关联的业务活动，因为业务落地和实施中往往会因为时间、资源、业务价值等原因而使用临时方案堆积和粗制滥造，最终陷入业务泥潭和技术债务。

有了系统化思维和多层次维度的矩阵思维的加入，我们的思考会更加全面，业务更能抽象出标准化和定制化结合的业务流程，这套“复杂度治理”的体系会更加完整。

# **从if-else说起** #

我经常说，我们不要做一个if-else coder。很显然，我说的if-else，不是说我们在coding的时候不能使用if-else，而是说我们不应该简陋的用if-else去实现业务的分支流程，因为这样随意的代码堆砌很容易堆出一座座“屎山”。

业务的差异性是if-else的根源。以零售通的商品业务为例。不同的处理场景，其业务逻辑实现是有差异性的。如下图所示，商品业务的差异性，主要体现在商品类型、销售方式和仓储方式的不同。

![1e930f10eeb9e1985714c31c62f4555a.png][]

这三个维度上的差异组合起来，有2x3x2 = 12之多。这就是为什么在老代码中，到处可以看到if(组合品) blabla,if(赠品) blabla,if(实仓) blabla之类的代码。

那么，如何消除这些讨厌的if-else呢，我们可以考虑以下两种方式：

1.  多态扩展：利用面向对象的多态特性，实现代码的复用和扩展(解决代码层面的复用)。
2.  代码分离：对不同的场景，使用不同的流程代码实现。这样很清晰，但是可维护性不好（流程复用度低、可维护性差）。

## ##

### **多态扩展** ###

多态扩展可以有继承和组合两种方式。继承勿用多言，组合有点像策略模式，也就是把需要扩展的部分封装、抽象成需要被组合的对象，然后对其进行扩展，比如阿里巴巴业务中台-星环的能力扩展点就是这种方式。

这里，我们举一个继承的例子，商品在上架的时候要检查商品的状态是否可售，普通商品（Item）检查自己就好了，而组合商品（CombineItem）需要检查每一个子商品。

用过程式编码的方式，很容易就能写出如下的代码：

public void checkSellable(Item item){
               if (item.isNormal()){
                   item.isSellable();            //省略异常处理        }        else{
                   List<Item> childItems = getChildItems();            childItems.forEach(childItem -> childItem.isSellable());            //省略异常处理        }
        }

然而，这个实现不优雅，不满足开闭原则--OCP(对功能扩展开放，对代码修改即对业务主逻辑是关闭的)，也缺少业务语义显性化的表达。更好的做法是，我们可以把CombineItem和Item的关系通过模型显性化的表达出来。

![32dc0b6d1ad9d294e44acb99c0b94510.png][]

这样一来，一方面模型正确的反应了实体关系，更清晰了。另一方面，我们可以利用多态来处理CombineItem和Item的差异，扩展性更好。重构后，代码会变成：

public void checkSellable(Item item){
               if (!item.isSellable()){
                   throw new BizException("商品的状态不可售，不能上架");        }    }

## **代码分离** ##

所谓的代码分离是指，对于不同的业务场景，我们用不同的编排代码将他们分开。以商品上架为例，我们可以这样写：

/**     * 1. 普通商品上架     */    public void itemOnSale(){
               checkItemStock();//检查库存        checkItemSellable();//检查可售状态        checkItemPurchaseLimit();//检查限购        checkItemFreight();//检查运费        checkItemCommission();//检查佣金        checkItemActivityConflict();//检查活动冲突
            generateCspuGroupNo();//生成单品组号        publishItem();//发布商品    }
        /**     * 2. 组合商品上架     */    public void combineItemOnSale(){
               checkCombineItemStock();//检查库存        checkCombineItemSellable();//检查可售状态        checkCombineItemPurchaseLimit();//检查限购        checkCombineItemFreight();//检查运费        checkCombineItemCommission();//检查佣金        checkCombineItemActivityConflict();//检查活动冲突
            generateCspuGroupNo();//生成单品组号        publishCombineItem();//发布商品    }        /**     * 3. 赠品上架     */    public void giftItemOnSale(){
               checkGiftItemSellable();//检查可售状态        publishGiftItem();//发布商品    }

这种方式，当然也可以消除if-else，彼此独立，也还清晰。但代码不具备横向的扩展性。简而言之就是同样是商品上架功能，如果有新的品类的商品需要上架那这块的上架的代码还需要用代码来组织，这段组织业务逻辑（业务流程）的代码无法复用，如此下去会造成非常多的上架流程相关的业务逻辑代码，系统熵增，维护性越来越差。

# #

## **矩阵分析** ##

细心的你可能已经发现了，在上面的案例中，普通商品和组合商品的业务流程基本是一样的。如果采用两套编排代码，有点冗余，这种重复将不利于后期代码的维护，会出现散弹式修改（一个业务逻辑要修改多处-即修改扩散）的问题。

一个极端情况是，假如普通商品和组合商品，只有checkSellable()不一样，其它都一样。那毫无疑问，我们使用有多态（继承关系）的CombineItem和Item来处理差异，会更加合适。

而赠品上架的情况恰恰相反，它和其他商品的上架流程差异很大。反而不适合和他们合用一套流程代码，因为这样反而会增加他人的理解成本。还不如单独起一个流程来的清晰。

个么，问题来了，我们什么时候要用多态来处理差异，什么时候要用代码分离来处理差异呢？

接下来，就是今天我要重点为你介绍的矩阵分析法。

我们可以弄一个矩阵，纵列代表业务场景（普通品+实仓、普通品+云仓、组合品+实仓），横列代表商业能力，里面的内容代表在这个业务场景下的业务活动的详细业务流程。对于我们的商品业务，我们可以得到如下的矩阵：

![34a8fdfb0ccc25d7caead17a4122e346.png][]

通过上面的矩阵分析，我们不难看出普通品和组合品可以复用同一套流程编排代码，而赠品和出清品的业务相对简单，更适合有一套独立的编排代码，这样的代码结构会更容易理解。

问题

1 对于商业能力(聚合多种业务场景)的可复用的系统服务，只能提供标准化的业务流程或模板化的业务流程对外提供标准化的系统服务。对于业务流程差异较大的业务场景就无法兼容和封装到标准化的流程中。

2 对于业务流程中的业务活动，不同的业务场景也存在不同的业务逻辑片段，需要具备逻辑片段的扩展性。

3 需要解决商业能力中业务流程中的流程编排代码可插拔性和编排性。

4 需要解决不同业务场景的流程编排和业务活动的可插拔和编排；

5 需要解决同一场景的业务流程中的业务活动的动态可插拔和编排。

# **矩阵思维（系统化多维度思考）** #

上面的案例不是我臆造出来的，而是我在和张文（我同事）讨论应该用哪种方式去处理业务差异的真实故事。

我记得在和大讨论完，开车回去的路上，我一直在想这个问题，然后在第二个路口等红灯的时候，突然有一个灵感冒出来。我抑制不住兴奋，一边开车，一边发消息给张文说：“我想到了一个很NB的方法论，能解决在‘多态扩展’和‘代码分离’之间如何做选择的问题”。这个问题的本质是统一业务流程中的活动节点的多态性扩展和不同业务场景（差异性较大的业务流程）之间的区分和识别。

其实，我知道我兴奋的不仅仅是解决了这个问题。我兴奋的是，我第一次真正领悟到了多维度思考的重要性。从而有机会从一个“单维度”生物，升级成一个“多维度”思考者。妈妈再也不用担心我被那些思维层级高的人，进行“降维打击”了。

结构化思维很有用，非常有用，只是它更多关注的是单向维度的事情。比如我要拆解业务流程，我要分解老板给我的工作安排，我要梳理测试用例，都是单向维度的。

而矩阵分析是两个维度的，当问题涉及的要素比较多，彼此关联关系很复杂的时候，两个维度肯定会比一个维度要来的清晰，这也是为什么说矩阵思维是比结构化思维更高层次的思维方式。

有了这些感悟，我开始系统的整理关于矩阵分析和多维度思考的资料，发现这种思维方式真是无处不在。

比如，用来对产品发展前景进行分析的波士顿矩阵。

![93a364bc9ff327f8acaaa66af9843fb5.png][]

又如，我之前在1688做交易下单业务的时候，有非常多的下单场景，每种场景下，买家享受的权益是不一样的（如下表所示）。我们当时也是使用了矩阵去表达这个复杂的关系，只是当时还没有想到要将其提升到方法论的高度。

![48c392c9524b51a0831d821332c73203.png][]

再比如，在数据分析中，维度分析是非常重要的，特别是维度很多的时候，我们可以通过皮尔逊积矩相关系数，做交叉分析，从而弥补独立维度分析没法发现的一些问题。

由此可见，这种矩阵分析的方式的确是对复杂业务进行分析的一把利器，业务场景越是多，交叉关联关系越是复杂，越需要这样的分析。

除此之外，生活中也到处可见多维思考的重要性。

比如，我们说浪费可耻，应该把盘子舔的很干净，岂不知加上时间维度之后，你现在的舔盘，后面可能要耗费更多的资源和精力去减肥，反而造成更大的浪费。

我们说代码写的丑陋，是因为要“快速”支撑业务，加上时间维度之后，这种临时的妥协，换来的是意想不到的bug，线上故障，以及无止尽的996。

简单的思考是“点”状的，比如舔盘、代码堆砌就是当下的“点”；好一点的思考是“线”状，加上时间线之后，不难看出“点”是有问题的；再全面一些的思考是“面”（二维）；更体系化的思考是“体”（三维）；比如，RFM模型就是一个很不错的三维模型。

![9b013325b7df03474967961ae577a438.png][]

# **复杂业务治理总结** #

在前言部分，我已经说过了，矩阵分析是对之前方法论的升级。加上以前的方法论，完整的方法论应该是“业务理解-->领域建模-->流程分解-->矩阵分析”（业务流程抽象）。

再配合COLA架构，我有信心说，在征服复杂度这头怪兽的路上，我们又向前迈进了一步。

为了方便大家理解，下面我把这些方法论做一个简单的串联和解释。

## **业务理解** ##

理解业务是所有工作的起点。首先，我们要找到业务的核心要素，理解核心概念，梳理业务流程。

比如，在零售通的商品域，我们要知道什么是商品（Item），什么是单品（CSPU），什么是组合品（CombineItem）。在下单域，我们要知道订单（order）的构成要素是商品、优惠、支付。在CRM领域，我们要理解客户、机会、联系人、Leads等等。

这里，我想再次强调下语言的重要性，语言是我们思考的载体，就像维特根斯坦说的：“凡是能够说的事情，都能够说清楚”

你不应该放过任何一个模糊的业务概念，一定要透彻的理解它，并给与合理的命名（Ubiquitous Language）。唯有如此，我们才能更加清晰的理解业务，才能更好的开展后续的工作。

## **领域建模** ##

在软件设计中，模型是指实体，以及实体之间的联系，这里需要我们具备良好的抽象能力。能够透过庞杂的表象，找到事务的本质核心。

再复杂的业务领域，其核心概念都不应该太复杂，抓住了核心，我们就抓住了主线，业务往往都是围绕着这些核心实体展开的。

比如，商品域虽然很复杂，但其核心的领域模型，无外乎就如下图所示：

![768edbf580577d67a4d00905366fd7f5.png][]

# #

## **流程分解** ##

关于流程分解，在《一文教会你如何写复杂业务代码》里面已经有非常详细的阐述，这里就不赘述了。

简单来说，流程分解就是对业务过程进行详细的分解，使用结构化的方法论（先演绎、后归纳），最后形成一个金字塔结构。

比如，在商品领域，有创建商品、商品上架、上架审核、商品下架、下架审核、修改商品、删除商品等一些列动作（流程），每个动作的背后都有非常复杂的业务逻辑。我们需要对这些流程进行详细的梳理，然后按步骤进行分解。最后形成一个如下的金字塔结构：

![ce5731b0b1314ebb39d746da507e83dd.png][]

# #

## **矩阵分析** ##

关于矩阵分析，我想我前面应该已经说清楚了。

业务的复杂性主要体现在流程的复杂性和多维度要素相互关联、依赖关系上，结构化思维可以帮我们梳理流程，而矩阵思维可以帮忙我们梳理、呈现多维度关联、依赖关系。二者结合，可以更加全面的展现复杂业务的全貌。从而让我们的治理可以有的放矢、有章可循。

既然是方法论，在这里，我会尝试给出一个矩阵分析的框架。试想下，如果我们的业务很简单，只有一个业务场景，没有分支流程。我们的系统不会太复杂。之所以复杂，是因为各种业务场景互相叠加、依赖、影响。

因此，我们在做矩阵分析的时候，纵轴可以选择使用业务场景，横轴是备选维度，可以是受场景影响的业务流程（如文章中的商品流程矩阵图），也可以是受场景影响的业务属性（如文章中的订单组成要素矩阵图），或者任何其它不同性质的“东西”。

![daf6705fc830ce5c13007a2161158ab1.png][]

通过矩阵图，可以清晰的展现不同场景下，业务的差异性。基于此，我们可以定制满足差异性的最佳实现策略，可能是多态扩展，可能是分离的代码，也可能是其它。

这就是矩阵分析的要义，其本质是一种系统化多维度思考的方法论。

[d9b741ec3eae9360bfff76f94ba77e05.png]: /images/20221123/7cbb74cd5e8347c1b0c372b842eaf97d.png
[-]: https://mp.csdn.net/console/editor/html/106772342
[1e930f10eeb9e1985714c31c62f4555a.png]: /images/20221123/9a37c7b49b4b400093b1f8db15305aad.png
[32dc0b6d1ad9d294e44acb99c0b94510.png]: /images/20221123/471dd0c1111842f59f341660604968c1.png
[34a8fdfb0ccc25d7caead17a4122e346.png]: /images/20221123/6c89b39f431840feabef8bad21535579.png
[93a364bc9ff327f8acaaa66af9843fb5.png]: /images/20221123/ee6e501c08784df389bc78728480890e.png
[48c392c9524b51a0831d821332c73203.png]: /images/20221123/74f745669f4c475bb04098bd37c56f9f.png
[9b013325b7df03474967961ae577a438.png]: /images/20221123/ac3065f06ffe447a897611c2cbf3eabc.png
[768edbf580577d67a4d00905366fd7f5.png]: /images/20221123/df06226d375f4163ba73b79b1934f771.png
[ce5731b0b1314ebb39d746da507e83dd.png]: /images/20221123/a451b7c42044464685d25d15eaff14a2.png
[daf6705fc830ce5c13007a2161158ab1.png]: /images/20221123/263a83d696f1428593e248ded1670d16.png