CRM系統化整合從N-1做減法實踐

京銷易系統已經接入大網、KA以及雲倉三個條線商機，每個條線商機規則差異比較大，當前現狀是獨立實現三套系統分別做支撐。 ...

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人日左右。

條線接入工時如下：