1 背景

京銷易系統(tǒng)已經(jīng)接入大網(wǎng)、KA以及云倉三個條線商機，每個條線商機規(guī)則差異比較大，當前現(xiàn)狀是獨立實現(xiàn)三套系統(tǒng)分別做支撐。

2 目標

2022年下半年CRM目標是完成9個新條線業(yè)務接入，完成銷售過程線上化，實現(xiàn)銷售規(guī)則統(tǒng)一。

3 問題

• 前端實現(xiàn)數(shù)據(jù)存儲與邏輯代碼耦合一起，無法復用，無法擴展，組件化拆分難度大。
• 組件拆分顆粒度較大，業(yè)務功能抽象不充分，缺乏復用性。
• 代碼重復編寫，相似功能冗余嚴重，開發(fā)和維護效率低。
• 代碼版本多，接口不統(tǒng)一，開發(fā)、運維成本高，難擴展。
• 每個條線階段、條線內(nèi)每個商機階段推進規(guī)則都是通過代碼單獨實現(xiàn)，開發(fā)、維護成本高，規(guī)則調(diào)整都需要代碼調(diào)整并上線，時效性低，同時階段規(guī)則維護在代碼中，無法直觀呈現(xiàn)和規(guī)則統(tǒng)一收口，運維難度大。

4 實現(xiàn)

4.1 方案調(diào)研

方案調(diào)研階段，針對業(yè)務場景，多次組會對于底層實現(xiàn)方案進行充分討論，列舉每個方案優(yōu)劣勢，選擇最適合當前業(yè)務場景的解決方案，最終選擇上圖的框架升級方案。

4.2 方案設(shè)計

4.2.1 設(shè)計思路

快速實現(xiàn)相似業(yè)務，減少相似代碼，通過前端組件化、后端服務標準化、商機階段配置化技術(shù)手段，支持各條線快速復用和靈活擴展。

4.2.2 前端組件化

1.前端現(xiàn)狀

數(shù)據(jù)存儲與邏輯代碼耦合在一起，無法復用，無法擴展，組件化拆分難度大。表現(xiàn)為mixins邏輯代碼與store數(shù)據(jù)存儲耦合在一起，既降低了代碼的可讀性，也降低了store數(shù)據(jù)讀寫的靈活性。舉個栗子，在人員信息集合中，本來可以針對name和sex兩個字段在各自的組件進行維護即可，可現(xiàn)實是兩個組件不得不調(diào)用同一個mixins進行維護。

組件拆分顆粒度較大，業(yè)務功能抽象不充分，缺乏復用性。組件的拆分沒有一個清晰的界限，沒有依據(jù)業(yè)務功能進行拆分，導致有一些組件不夠純粹，不符合單一職責原則，無法復用。在后期的維護過程中組件逐漸變得臃腫不堪。

代碼重復編寫，相似功能冗余嚴重，開發(fā)和維護效率低。由于組件無法復用，在后期維護過程中，開發(fā)人員對于類似的功能，不得不寫了很多相似的代碼，致使整個項目代碼冗余、重復，慢慢的變得不可維護。

2.解決方案

針對本次商機條線接入功能，采用現(xiàn)有技術(shù)方案很難對后續(xù)條線依次接入，一個條線一套代碼實現(xiàn),接入周期長人力成本高，按期完成目標是一項不可能完成的挑戰(zhàn)。經(jīng)過技術(shù)方案調(diào)研，決定搭建一套求同存異（同為各個條線共用部分，異為各個條線單獨部分）的前端組件化方案。依據(jù)業(yè)務功能，抽象出獨立業(yè)務組件模塊，依據(jù)條線插拔式組裝，搭建出可維護、可擴展、靈活性高的組件積木化方案，在業(yè)務擴展性比較強的前端模塊架構(gòu)中優(yōu)勢更加明顯。

組件積木化方案特點如下：

1.方案采用積木化前端組件搭建，其中任何一個組件都可以被替換（webComponent），任何一個父組件都可以擴展n個子組件。以上圖商機信息組件為例，各條線商機信息所包含的字段存在差異，每個條線所對應的商機信息組件不同，最終會根據(jù)條線選擇對應的組件加載。

2.數(shù)據(jù)統(tǒng)一管理（store），組件和數(shù)據(jù)之間為更新和依賴關(guān)系，當有組件更新數(shù)據(jù)時，其他組件也會立即更新，而不用相互傳值。以商機詳情組件為例，商機詳情中修改了商機名稱字段，則所有用到商機名稱的組件都會得到更新。這需要提前對組件和store進行數(shù)據(jù)依賴更新的建立，通過computed與store雙向依賴和監(jiān)控機制，當computed監(jiān)聽store數(shù)據(jù)變化，將變化的數(shù)據(jù)更新到組件上，組件中通過store的mutaions更新數(shù)據(jù)到store上。

商機詳情組件化抽象示意圖如下：

4.2.3 后端標準化后端現(xiàn)狀

由于前期未對條線的領(lǐng)域模型和功能模塊進行抽象，導致煙囪代碼林立；每個條線接入都要重復開發(fā)多套代碼，各端（PC、移動端）接口不統(tǒng)一，前后端聯(lián)調(diào)對接接口都需要區(qū)分多套；各條線獨立開發(fā)部署，隨著系統(tǒng)功能的豐富以及產(chǎn)品線持續(xù)增加，個性化需求和缺陷修復極大的消耗了研發(fā)資源和精力。同時，無法滿足各條線商機階段推進可定制的業(yè)務訴求，大致狀態(tài)如下圖。

2.解決方案

通過梳理商機流程與功能可以發(fā)現(xiàn)，商機中各條線既有相同的功能模塊，也有各自獨有的功能，例如商機創(chuàng)建、關(guān)閉、激活等流程每個條線差異不大，但是有些相似的功能模塊各條線也存在差異，例如大宗的關(guān)閉商機與服務+中的關(guān)閉商機各自的關(guān)閉條件就不一樣；那么基于此種業(yè)務場景，首先我們需要將主流程抽象出標準服務能力；例如，商機創(chuàng)建流程，我們將其定義為權(quán)限校驗、參數(shù)校驗、額外特殊校驗、補充信息、模型轉(zhuǎn)換、保存數(shù)據(jù)、跨區(qū)校驗、后續(xù)額外處理等標準模板服務；每一個步驟方法都是抽象的，后續(xù)每個條線都將繼承它，可以重寫自己的邏輯；這樣一個創(chuàng)建商機流程就標準化了。

上述我們是根據(jù)業(yè)務特性進行的模板抽象固化，但是如何將整個架構(gòu)按照條線來走呢，這就需要我們將每個條線的流程進行抽象，例如，幾乎每個條線都有創(chuàng)建商機、關(guān)閉商機、激活商機、修改商機等相同的動作，我們需要將這些抽象成固定的接口；然后各自條線都實現(xiàn)該接口并聲明成策略，根據(jù)入?yún)⒌淖R別自動分流至不同條線策略處理；也就形成了按條線為策略錨點的模式。

所以總體上是利用策略模式 + 模板模式支持各條線快速復用和靈活擴展，整體服務抽象復用及擴展思路形成大致的核心類圖如下圖：

整個商機的后端架構(gòu)經(jīng)過單條線多套接口處理的方式調(diào)整為適配所有條線統(tǒng)一接口接入；后端整體架構(gòu)大致分5層，在核心層其實還會細分邏輯層，代理層以及Mapper 層。

首先我們在這次改造過程中統(tǒng)一了接口層，不在區(qū)分PC端接口，JME 端接口，統(tǒng)一以JSF接口形式提供出去；然后借助物流網(wǎng)關(guān)配置PC認證以及JME認證并一致以Http協(xié)議對接出去，保證了接口層面的統(tǒng)一。在適配層我們是定義了一個策略適配器，它會掃描所有聲明了注解@LineType的策略處理器并緩存，然后根據(jù)解析入?yún)⒅械臈l線進行自動匹配處理器進行分配處理，從而達到請求的自動分配處理。在核心層中其實更多的是模板方法的抽象與封裝，將商機的基本查詢、基礎(chǔ)CMD操作、以及商機相關(guān)聯(lián)信息操作進行分類抽象。將商機的推進機制建立在規(guī)則引擎中，將每個條線的推進規(guī)則提前配置在規(guī)則引擎的規(guī)則表中，并在后端服務中統(tǒng)一提供一個推進入口，所有條線都將基于該入口進行推進，達到推進規(guī)則明確，入口統(tǒng)一，階段可配置等可靈活擴展的方式。

通過整體架構(gòu)的優(yōu)化和調(diào)整后，目前已經(jīng)可以適配所有條統(tǒng)一接入、商機階段可配置，推進規(guī)則可定義、接口統(tǒng)一等優(yōu)點，大大節(jié)省了研發(fā)的接入成本。

4.2.4 商機階段配置化

1.場景現(xiàn)狀

每個銷售條線的商機流程階段及相應規(guī)則都存在差異，甚至同一個銷售條線也存在多種業(yè)務，對應的商機流程階段也不同，為支持多銷售條線的差異化商機業(yè)務；要求必須實現(xiàn)每個條線的商機階段個數(shù)是可配置的，并且每個階段的規(guī)則也是可配置。

2.方案選型

如下圖中所示，列舉了幾個條線的商機階段生命周期，幾乎每個條線的商機生命周期都不一樣，這里需要說明一下階段與階段之間的推進條件是允許不一樣的，所以會存在不同條線存在相同的階段，但其實到達該階段的前置條件是有可能不一樣的，這就要求階段的規(guī)則是可配置的，這也會造成可復用的可能性小。如果通過編碼方式去實現(xiàn)每個條線的階段生命周期會是一個非常復雜的過程，并且也難以維護。

經(jīng)過調(diào)研發(fā)現(xiàn)，我們的這種場景模型就是通過多個入?yún)l件決定流程走向（通過、不通過）的一種簡單形式，相對于多入多出的模式還簡單一些，而這種模式正好現(xiàn)在已經(jīng)有比較好的解決方案（規(guī)則引擎），在現(xiàn)有的流程引擎（Flowable、Activity）都有對規(guī)則引擎的實現(xiàn)，包括強大的Drools 規(guī)則引擎。對比幾款規(guī)則引擎幾乎都可以很好的滿足我們的需求，那就要考慮成本問題，畢竟引入一款中間件對系統(tǒng)的維護成本也是比較大的。經(jīng)過了解部門內(nèi)部已經(jīng)對Flowable 已經(jīng)進行二次封裝對外賦能了，所以在這邊我們采用了基于Flowable 流程引擎中的DMN來實現(xiàn)，從模型上來說就是輸入多個入?yún)ⅲ缓蟾鶕?jù)規(guī)則配置進行判斷走向，沒有多分支相關(guān)聯(lián)，所以選擇Flowable 的規(guī)則引擎也比較合適。

解決方案：通過規(guī)則引擎，配置商機階段和階段推進規(guī)則，解決各條線商機階段差異化問題，將變化流程用配置化方式融入到整體流程中。

3.實現(xiàn)效果

在規(guī)則引擎中，提供決策表的表達式，決策表分為輸入表達式與輸出表達式兩個主要區(qū)域。在輸入表達式中，可以定義變量，用于規(guī)則輸入項(input entries)的表達式。可以通過選擇Add Input(添加輸入)，定義多個輸入表達式。在輸出表達式中，可以定義選擇表執(zhí)行結(jié)果要創(chuàng)建的變量（變量的值將用于輸出項表達式，在下面解釋）?？梢酝ㄟ^選擇Add Output(添加輸出)，定義多個輸出表達式。

規(guī)則配置如下圖：（以服務+條線舉例）

服務+ 權(quán)授權(quán)業(yè)務商機推進規(guī)則:jd-rule-crm_fwj_chance_authorized_business

服務+ B線上業(yè)務商機推進規(guī)則:jd-rule-crm_fwj_chance_b_online_business

優(yōu)勢：

1. 規(guī)則統(tǒng)一收口，每個條線商機階段推進規(guī)則可以直觀呈現(xiàn)，規(guī)則演化軌跡可以追蹤，避免問題排查時，通過代碼排查方式核對規(guī)則，提升運維效率。
2. 規(guī)則調(diào)整可以實時生效，避免代碼維護和系統(tǒng)上線，提升研發(fā)效率。
3. 一套代碼實現(xiàn)所有條線階段推進，只需要根據(jù)條線添加不同的輸入即可。

5 效果

5.1 提升效率

消滅煙囪系統(tǒng)，一套系統(tǒng)完成所有條線支撐，實現(xiàn)各條線、各端接口統(tǒng)一。

開發(fā)成本低，易擴展，提升研發(fā)效率，降低運維成本；

按照領(lǐng)域?qū)ι虣C進行拆分解耦，實現(xiàn)商機領(lǐng)域獨立部署，在商機領(lǐng)域內(nèi)，通過前端組件化、后端服務標準化、商機階段配置化技術(shù)手段，支持各條線快速復用和靈活擴展。接入對比結(jié)果來看，研發(fā)效率提升顯著，同時也降低運維成本。隨著標準流程不斷抽象，底層基礎(chǔ)服務不斷完善，后續(xù)條線接入的效率在進一步提升，從后續(xù)接入的云倉生態(tài)、物流科技、價值供應鏈，供應鏈金融，新業(yè)務-新業(yè)務、金融、供應商7個條線來看，平均接入工時維持在30人日左右。

條線接入工時如下：

標準流程和通用基礎(chǔ)服務，提升研測過程效率，其中：服務+條線接入測試工時從最初評估的30人日到實際的23人日，測試階段效率提升23.3%:

大宗條線接入測試評估工時及實際工時，基于服務+接入商機項目的測試經(jīng)驗，大宗商機接入項目測試階段從原計劃30人日降低到10人日，效率提升66.7%：

5.2 提升質(zhì)量

服務+較原計劃提前4工作日交付，大宗較原計劃提前11工作日交付，交付演示過程中均未出現(xiàn)任何問題，驗收全程未出現(xiàn)影響整體進度的阻塞性問題。

大宗UAT過程中共提出6個問題，其中5個為頁面調(diào)優(yōu)等優(yōu)化項，1個為環(huán)境引起的無法勾選問題，未出現(xiàn)任何bug類問題，整體驗收過程順暢無阻。

作者：京東物流 姚再毅 孔祥東 樊平安 楊攀 田雷雷

來源：京東云開發(fā)者社區(qū) 自猿其說Tech文章來源地址http://www.zghlxwxcb.cn/news/detail-599185.html

到了這里，關(guān)于CRM系統(tǒng)化整合從N-1做減法實踐的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！