京销易系统已经接入大网、KA以及云仓三个条线商机，每个条线商机规则差异比较大，当前现状是独立实现三套系统分别做支撑。
2022年下半年CRM目标是完成9个新条线业务接入，完成销售过程线上化，实现销售规则统一。
方案调研阶段，针对业务场景，多次组会对于底层实现方案进行充分讨论，列举每个方案优劣势，选择最适合当前业务场景的解决方案，最终选择上图的框架升级方案。
快速实现相似业务，减少相似代码，通过前端组件化、后端服务标准化、商机阶段配置化技术手段，支持各条线快速复用和灵活扩展。
1.前端现状
数据存储与逻辑代码耦合在一起，无法复用，无法扩展，组件化拆分难度大。表现为mixins逻辑代码与store数据存储耦合在一起，既降低了代码的可读性，也降低了store数据读写的灵活性。举个栗子，在人员信息集合中，本来可以针对name和sex两个字段在各自的组件进行维护即可，可现实是两个组件不得不调用同一个mixins进行维护。
组件拆分颗粒度较大，业务功能抽象不充分，缺乏复用性。组件的拆分没有一个清晰的界限，没有依据业务功能进行拆分，导致有一些组件不够纯粹，不符合单一职责原则，无法复用。在后期的维护过程中组件逐渐变得臃肿不堪。
代码重复编写，相似功能冗余严重，开发和维护效率低。由于组件无法复用，在后期维护过程中，开发人员对于类似的功能，不得不写了很多相似的代码，致使整个项目代码冗余、重复，慢慢的变得不可维护。
2.解决方案
针对本次商机条线接入功能，采用现有技术方案很难对后续条线依次接入，一个条线一套代码实现,接入周期长人力成本高，按期完成目标是一项不可能完成的挑战。经过技术方案调研，决定搭建一套求同存异（同为各个条线共用部分，异为各个条线单独部分）的前端组件化方案。依据业务功能，抽象出独立业务组件模块，依据条线插拔式组装，搭建出可维护、可扩展、灵活性高的组件积木化方案，在业务扩展性比较强的前端模块架构中优势更加明显。
组件积木化方案特点如下：
1.方案采用积木化前端组件搭建，其中任何一个组件都可以被替换（webComponent），任何一个父组件都可以扩展n个子组件。以上图商机信息组件为例，各条线商机信息所包含的字段存在差异，每个条线所对应的商机信息组件不同，最终会根据条线选择对应的组件加载。
2.数据统一管理（store），组件和数据之间为更新和依赖关系，当有组件更新数据时，其他组件也会立即更新，而不用相互传值。以商机详情组件为例，商机详情中修改了商机名称字段，则所有用到商机名称的组件都会得到更新。这需要提前对组件和store进行数据依赖更新的建立，通过computed与store双向依赖和监控机制，当computed监听store数据变化，将变化的数据更新到组件上，组件中通过store的mutaions更新数据到store上。
商机详情组件化抽象示意图如下：
由于前期未对条线的领域模型和功能模块进行抽象，导致烟囱代码林立；每个条线接入都要重复开发多套代码，各端（PC、移动端）接口不统一，前后端联调对接接口都需要区分多套；各条线独立开发部署，随着系统功能的丰富以及产品线持续增加，个性化需求和缺陷修复极大的消耗了研发资源和精力。同时，无法满足各条线商机阶段推进可定制的业务诉求，大致状态如下图。
2.解决方案
通过梳理商机流程与功能可以发现，商机中各条线既有相同的功能模块，也有各自独有的功能，例如商机创建、关闭、激活等流程每个条线差异不大，但是有些相似的功能模块各条线也存在差异，例如大宗的关闭商机与服务+中的关闭商机各自的关闭条件就不一样；那么基于此种业务场景，首先我们需要将主流程抽象出标准服务能力；例如，商机创建流程，我们将其定义为权限校验、参数校验、额外特殊校验、补充信息、模型转换、保存数据、跨区校验、后续额外处理等标准模板服务；每一个步骤方法都是抽象的，后续每个条线都将继承它，可以重写自己的逻辑；这样一个创建商机流程就标准化了。
上述我们是根据业务特性进行的模板抽象固化，但是如何将整个架构按照条线来走呢，这就需要我们将每个条线的流程进行抽象，例如，几乎每个条线都有创建商机、关闭商机、激活商机、修改商机等相同的动作，我们需要将这些抽象成固定的接口；然后各自条线都实现该接口并声明成策略，根据入参的识别自动分流至不同条线策略处理；也就形成了按条线为策略锚点的模式。
所以总体上是利用策略模式 + 模板模式支持各条线快速复用和灵活扩展，整体服务抽象复用及扩展思路形成大致的核心类图如下图：
整个商机的后端架构经过单条线多套接口处理的方式调整为适配所有条线统一接口接入；后端整体架构大致分5层，在核心层其实还会细分逻辑层，代理层以及Mapper 层。
首先我们在这次改造过程中统一了接口层，不在区分PC端接口，JME 端接口，统一以JSF接口形式提供出去；然后借助物流网关配置PC认证以及JME认证并一致以Http协议对接出去，保证了接口层面的统一。在适配层我们是定义了一个策略适配器，它会扫描所有声明了注解@LineType的策略处理器并缓存，然后根据解析入参中的条线进行自动匹配处理器进行分配处理，从而达到请求的自动分配处理。在核心层中其实更多的是模板方法的抽象与封装，将商机的基本查询、基础CMD操作、以及商机相关联信息操作进行分类抽象。将商机的推进机制建立在规则引擎中，将每个条线的推进规则提前配置在规则引擎的规则表中，并在后端服务中统一提供一个推进入口，所有条线都将基于该入口进行推进，达到推进规则明确，入口统一，阶段可配置等可灵活扩展的方式。
通过整体架构的优化和调整后，目前已经可以适配所有条统一接入、商机阶段可配置，推进规则可定义、接口统一等优点，大大节省了研发的接入成本。
1.场景现状
每个销售条线的商机流程阶段及相应规则都存在差异，甚至同一个销售条线也存在多种业务，对应的商机流程阶段也不同，为支持多销售条线的差异化商机业务；要求必须实现每个条线的商机阶段个数是可配置的，并且每个阶段的规则也是可配置。
2.方案选型
如下图中所示，列举了几个条线的商机阶段生命周期，几乎每个条线的商机生命周期都不一样，这里需要说明一下阶段与阶段之间的推进条件是允许不一样的，所以会存在不同条线存在相同的阶段，但其实到达该阶段的前置条件是有可能不一样的，这就要求阶段的规则是可配置的，这也会造成可复用的可能性小。如果通过编码方式去实现每个条线的阶段生命周期会是一个非常复杂的过程，并且也难以维护。
经过调研发现，我们的这种场景模型就是通过多个入参条件决定流程走向（通过、不通过）的一种简单形式，相对于多入多出的模式还简单一些，而这种模式正好现在已经有比较好的解决方案（规则引擎），在现有的流程引擎（Flowable、Activity）都有对规则引擎的实现，包括强大的Drools 规则引擎。对比几款规则引擎几乎都可以很好的满足我们的需求，那就要考虑成本问题，毕竟引入一款中间件对系统的维护成本也是比较大的。经过了解部门内部已经对Flowable 已经进行二次封装对外赋能了，所以在这边我们采用了基于Flowable 流程引擎中的DMN来实现，从模型上来说就是输入多个入参，然后根据规则配置进行判断走向，没有多分支相关联，所以选择Flowable 的规则引擎也比较合适。
解决方案：通过规则引擎，配置商机阶段和阶段推进规则，解决各条线商机阶段差异化问题，将变化流程用配置化方式融入到整体流程中。
3.实现效果
在规则引擎中，提供决策表的表达式，决策表分为输入表达式与输出表达式两个主要区域。在输入表达式中，可以定义变量，用于规则输入项(input entries)的表达式。可以通过选择Add Input(添加输入)，定义多个输入表达式。在输出表达式中，可以定义选择表执行结果要创建的变量（变量的值将用于输出项表达式，在下面解释）。可以通过选择Add Output(添加输出)，定义多个输出表达式。
规则配置如下图：（以服务+条线举例）
服务+ 权授权业务商机推进规则:jd-rule-crm_fwj_chance_authorized_business
服务+ B线上业务商机推进规则:jd-rule-crm_fwj_chance_b_online_business
优势：
消灭烟囱系统，一套系统完成所有条线支撑，实现各条线、各端接口统一。
开发成本低，易扩展，提升研发效率，降低运维成本；
按照领域对商机进行拆分解耦，实现商机领域独立部署，在商机领域内，通过前端组件化、后端服务标准化、商机阶段配置化技术手段，支持各条线快速复用和灵活扩展。接入对比结果来看，研发效率提升显著，同时也降低运维成本。随着标准流程不断抽象，底层基础服务不断完善，后续条线接入的效率在进一步提升，从后续接入的云仓生态、物流科技、价值供应链，供应链金融，新业务-新业务、金融、供应商7个条线来看，平均接入工时维持在30人日左右。
条线接入工时如下：
标准流程和通用基础服务，提升研测过程效率，其中：服务+条线接入测试工时从最初评估的30人日到实际的23人日，测试阶段效率提升23.3%:
大宗条线接入测试评估工时及实际工时，基于服务+接入商机项目的测试经验，大宗商机接入项目测试阶段从原计划30人日降低到10人日，效率提升66.7%：
服务+较原计划提前4工作日交付，大宗较原计划提前11工作日交付，交付演示过程中均未出现任何问题，验收全程未出现影响整体进度的阻塞性问题。
大宗UAT过程中共提出6个问题，其中5个为页面调优等优化项，1个为环境引起的无法勾选问题，未出现任何bug类问题，整体验收过程顺畅无阻。
作者：京东物流 姚再毅 孔祥东 樊平安 杨攀 田雷雷
来源：京东云开发者社区 自猿其说Tech