With the increase of business channels and products, whether to start your code into a quagmire IF-ELSE composition, it is difficult to get out?
Channel properties continue to increase
Small yards students came to a new company, to be responsible for starting a new beginning, but with the background of the development projects unlimited imagination. Like all internet projects, business change very quickly, in order to reduce the initial cost of trial and error, small yards students chose popular and convenient anemia model, that is, Service + DAO / RPC structure, do a simple separation of concerns - business and infrastructure (storage / remote service) separation.
Business is to force, the main flow model has been gradually forming, but also added a lot of marketing channels, there are App within the company, there are public numbers, applets, H5, there are channels for various types of external partners, small yards students have been in the high-load work with, absolutely no time to think how to elegantly solve the problems caused by these channels to increase. However, each channel will have a small channel-related properties, which means that the login, registration, and so on to do business in each Service, while each additional channel, should increase some IF-ELSE statements about judgment channels judgment. Quantitative cause a qualitative change, when added to nearly ten channels, small yards ignorant force, the sort code logic is extremely difficult context, because read through the code, you need to be subject to interference nearly ten different channels branch code. At the same time the code becomes difficult to parallel development, expand the number of channels will be modified because of the same Service and more prone to conflict.
In fact, this small code may take another approach, into another dilemma, small yards students each additional channel will be a copy of the original code, and then make simple changes for the channel, then you can safely and efficiently complete business It needs. However, copy the code temporarily cool,It has been cool copyWhen we need to modify some of the common implementation of channels, sort out the difference between different channels of realization and modify, nearly ten channels will let us become the'd rather die.
Public sinking logic solutions
Small yards students to the next, no matter how busy have collapsed from this predicament, so he came up with the following solution:
将公共的逻辑下沉，将各个渠道特有的判断及逻辑都上提。如此一来我们可以从代码中分离渠道和公用业务逻辑——要理解渠道特性，我们可以从渠道所在模块(微服务/package/service)的代码得知，如果要理解通用的信息，则到公共
业务逻辑层查看对应的实现。
但若要使用本解决方案解决目前系统的问题，则需要引入大量的重构，因为该实现需要将大量已有存在的渠道逻辑变更其发生的逻辑时间点，这需要大量的开发及测试人力支持。
扩展点解决方案
于是小码同学开始在网上搜索相关的解决方案，了解到阿里有个可以解决类似问题的框架实现COLA，并以此为参考开展了自己的扩展点设计
https://github.com/alibaba/COLA其引入了一种名为 扩展点/插件 的机制（扩展点是一个Interface,扩展点实现为interface的一个特定实现），让我们可以达到以下效果：
要实现这个效果，强制我们把相关业务语义显式化，例如 通用业务逻辑Service在没有引入扩展点前，写的校验身份的代码为
if(is渠道B) {
渠道B的一大堆代码进行身份校验
} else {
默认实现的一大堆代码进行身份校验
}而引入扩展点后，在通用业务逻辑Service写的则是
校验身份扩展点.执行校验();其显式化了业务语义，并像 公用逻辑下沉 的解决方案一样 分离了主干的代码逻辑和特定实现的代码逻辑，还能保证原有特定渠道逻辑执行的相对位置不变。
在扩展点机制的支持下我们只需要定下规范——在通用业务逻辑层不能出现任何关于Channel渠道的IF-ELSE判断，这样就可收获大量有基础抽象的通用业务逻辑代码，提高识别基础抽象的能力。
扩展点解决方案的本质
扩展点本质上就是个带有自动路由功能的策略模式，其根据业务上下文信息，自动推断出应该选用哪个具体的扩展点实现。
扩展点的机制和原理简单，使用也很简单，但其给业务系统代码带来却是变革性的。
多维扩展问题的出现
小码同学利用扩展点已经阻止了渠道增加带来的代码腐化加剧问题，小码以保守起见：
- 对于没有任何业务变化的代码保持不变
- 对于新增的渠道使用扩展点来防止代码进一步腐化
- 对于存在业务变动的代码，在测试资源的支持下，利用扩展点重构原有代码，令代码变得新鲜
但新的问题出现了，项目中也有一个与渠道类似的，会不断扩展实现的概念——产品。
在小码的系统中，每增加一个产品也是按照类似先前增加渠道的形式，以IF-ELSE完成扩展。于是，小码希望直接套用之前的扩展点机制，然而事情并没有这么顺利。
在上一幅图中，contextCode为
companyY.channelB其表征的是渠道维度的身份信息，我们以该信息为依据，来匹配最适合的渠道相关的实现。与此类似，我们需要引入产品维度的身份信息，同时也要将不同维度的contextCode加以区分，然而COLA的实现中并不支持此类多维扩展实现，于是小码开始设计了自己的ConextCode及ImplementCode规范，增加了维度标识符：
channel:companyY.channelB
product:companyY.ProductO.subProductE通过维度标志，小码分开了不同维度的扩展点以及其对应的实现，解决了大部分的问题。
多维扩展点冲突问题
引入多维扩展点后，大多数扩展实现都在各自的维度良好运行，井水不犯河水。然而，有少数扩展点却出现了需要多维同时决定实现的场景，如：
当前若是渠道A且是产品X的情况下需要使用特定的扩展实现。目前基于维度隔离的扩展点感觉无法支持此类需求，于是，小码继续查找相关资料，了解到了阿里TMF2.0框架的实现：
https://segmentfault.com/a/1190000012541958TMF2.0按文中介绍，其为一个二维的扩展点实现，这两维分别是：
- 行业维度
- 一个行业维度的代码即为TMF2.0的业务身份
- 其等价于小码之前设计的没带维度标志的contextCode
- 产品维度
- 与本文中的产品设定完全不同，请勿套入理解
与小码之前设计的维度隔离扩展点不同，TMF2.0中行业维度与产品维度会共享扩展点，然而当出现扩展点冲突时，TMF2.0会以业务身份为线索，通过可视化界面配置特定业务身份在遇到扩展实现冲突时应该选择哪一个扩展实现，并将其固化成配置，运行时依据配置选择最终扩展实现。
然而该设定并不符合项目的现状，相关UI的开发设计也是一个巨大的工程，因此小码设计了另外一种折中的设定：
- 扩展点依然按维度隔离
- 当出现扩展点路由需要多维信息决策时，采用嵌套形式
- 不同扩展点不同维度的嵌套的次序，都按照固定的次序进行
如下图所示
This realization set although cumbersome, but in reality, the situation appears multidimensional expansion options to achieve common intervention should be relatively small, relative to the benefits derived extension points dimensions isolation, it should be acceptable.
Pleasant small code
Theoretical easy to use extension points, which makes
- The code has a main flow business abstract base such context clear
- Characteristics of the individual channels, the product of highly cohesive in the respective package
- After the main business processes mature, new products, channels no longer need to move the main business process code, simply add a new channel packages and package
- The code did not change the main business processes, reduce overall risk, reduce the amount of testing
- Extension involves only increase the corresponding channel product, which isolates the natural development of different working groups to improve the degree of parallelism
From small yards and his little friends from out of the 996, with the base faithful lived a happy life.
About the Author
Many years of experience in the financial industry, is now moving bricks Top2 work for a private bank senior, he had two TOP3 joint-stock commercial banks and a mutual Golden Venture Company (architecture, the main core business processes), EasyTransaction authors, welcome attention to individual public number, in here I will share the daily work and life thinking on architecture, coding and operations
