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