導讀

本文重點介紹了京東零售電商業務在訂單逆向履約上面的最佳技術實踐，京東零售快退平臺承接了零售幾乎所有售前逆向攔截和退款業務，併在長期的業務和技術探索中沉澱了豐富的業務場景設計方案、架構設計經驗，既能承接面向消費者C端用戶的高併發流量，同時也能滿足集團複雜業務的訂單信息流、貨品實物流、財務資金流的逆向精準攔截。本文通過對集團B-PaaS化技術方案進行系統整體的架構升級改造，總結歸納出涵蓋用戶解約流程管理、撤銷解約流程管理、訂單逆向退款信息管理、流程配置化和流程可視化一整套的解決方案，該方案經過多次探討和驗證，已支持集團多個戰略業務的增長。閱讀本文，讀者可以瞭解到整個快退平臺新系統設計的底層邏輯，也可以參考本文並結合實際場景，將方案應用在遺留債務系統改造、業務和技術建模中。

一、背景介紹

在集團PaaS化戰略引導下，筆者負責的閃電敏捷團隊在近半年完成了快退系統的解約和撤銷2個子系統的B-PaaS架構升級，在此基礎上，快退還完成配置化系統升級，無論業務支持、產品溝通和系統交付能力都實現了跨越式的突破。

1. 業務上的支持，以集團長城融合項目為始，通過PaaS化升級改造，在原有整單退業務上支持了訂單的SKU調整退業務，如不做PaaS化架構升級則需要重新構建調整退款系統支持；B商城項目中B和C端能力融合，與訂單中台側團隊合力在C端訂單原有狀態的節點上進行能力復用，完美融合了B商城的意向單逆向業務。在未來，還將擴展支持更多集團戰略項目。

2.產品上的支持，以集團複雜業務為底，快退平臺承接了集團零售幾乎所有售前逆向攔截和退款業務，業務複雜度極高，產品和研發日常只能以模塊到人的方式溝通，比如以商詳結算頁為例Handler業務處理器185，而快退側Handler業務處理器189不包含攔截器Interceptor，通過梳理合併相似業務流程，通用流程65+。通過PaaS化架構升級，不僅對業務建模、流程可視化，同時構建領域模型，沉澱一套核心業務流程，產品溝通的人員需求降低了83%。

3. 系統上的支持，集團在過去幾年不僅擴充了主站業務，同時進行了出海戰略、商業戰略的投入，構建了多個煙囪重覆系統，不僅在業務上很多能力相似，還增加了研發維護和投入成本。通過PaaS化架構升級，目前已將農批業務進行PaaS化架構支持，其他業務也在進行PaaS一套內核支持，多個垂直業務分包的融合。維護人員投入減少了一半。

二、產品介紹

2.1 快退是什麼？

2.1.1 快退在C端用戶消費者眼裡是什麼？

圖1 C端用戶視角下的快退

2.1.2 快退其他視角下是什麼？

C端：面向C端用戶完成支付前取消、支付完成後取消

商家：面向POP商家完成協助用戶代取消，面向門店商家

運營：面向自營產品，同POP商家代取消

客服：面向財務審核異常，以及用戶進線投訴取消

拒收：面向配送產品到顧客，聯繫不上或者用戶拒收

天網：面向黑名單用戶，套利或者逃運費的風控攔截

2.1.3 快退是什麼？

用一句話總結：快退平臺是面向消費者、商家、風控、客服等多種角色， 提供實物或者虛擬退款的解決方案，致力於打造售前解約方案一體化平臺。

三、領域建模

3.1 建模的價值和必要性

在建模前首先來看下圖，該圖主要講解了領域專家、項目經理、架構師、產研團隊等人如何進行協作，也是講述了建模的過程和必要性，尤其是統一語言、更好的還原業務真實度場景。

圖2 建模的過程和必要性

可以從中提取下關鍵詞：問題域、業務期望，業務流程圖、場景活動分析，業務邊界、團隊組織產品邊界以及技術實現的系統架構邊界。用一句話歸納下，在特定的業務場景下，明確該業務場景下的問題域，通過元素和關係來表述出業務規則，進行當前問題的解決方案輸出。

3.2 建模前的工作准備

3.2.1 明確目標

從巨集觀目標來說：企業架構(Enterprise Architecture)始於 20 世紀 60 年代，截至目前已有接近六十年的發展歷程，也誕生很多成熟的企業架構與方法，例如Zachman、TOGAF、DoDAF 等，這些企業架構框架被應用於各類企業和組織的頂層設計 。那麼通過對於企業架構的規劃和設計，可以幫助企業構建整體的數字化策略，規劃數字化項目，通過數字化的手段幫助其實現期望的戰略目標和業務結果， 形成企業的數字化頂層規劃與設計，指導企業的數字化轉型過程。

為了構建現代化企業架構，打破數據孤島，消滅煙囪重覆建設，利用PaaS化的方式落地業務中台架構，助力企業的數字化轉型，需要將現有業務系統進行業務流程梳理，識別差異化點，構建一套業務流程共用的內核，多個垂直化業務流程的擴展能力支持。

從微觀目標來說：業務系統在人員交替，資料不全，代碼堆砌，業務野蠻擴張的過程中，不斷加深了軟體複雜度的治理難度，從產品講不全業務背景，溝通不全產品能力，研發對於業務邏輯不敢修改，上線頻繁出現業務場景缺失驗證等問題。不僅加劇了產研交付周期，從需求吞吐量來說也逐步下降，只留下產研團隊在艱難的維護，制約了創新產品和業務的發展。

為了提升產研交付效率，降低交付周期，提升需求吞吐量，更好的支持為了產品的創新和業務創新發展，那麼就需要進行產品系統的精簡瘦身。

3.2.2 看清現狀

1. 從業務需求分析：如果讀者有固定的業務運營團隊，這裡可以依據業務運營團隊進行業務需求分析歸納和整理，以及未來的展望。如果沒有業務運營團隊，比如是基礎能力部門，往往對接的業務方非常多，這裡面就面臨一個困境：沒法與業務溝通，在這裡則可以進行以往業務需求分析，比如筆者要講的這個案例，從以往需求中進行歸類，分為需求重災區和輕災區。

圖3 業務需求分析的角度

2. 從問題空間分析：（1）業務問題：業務方多，業務需求不集中；（2）產品問題：產品對於業務需求把控弱，產品邊界模糊，行業缺少成熟方案，產研認知不統一；（3）系統問題：業務模式亂，依賴上下游多，業務流程複雜不易闡述清晰。

圖4 問題空間分析的角度

3.2.3 尋求解法

從上面可以看到，如果只是從業務建模其實無法避免上述所有的問題，業務-組織-技術-運營之間關係互相依賴。那麼就需要從兩個方面解決，一個是組織機制流程方面，可以把它歸納為需求和產品管理；另外一個是系統業務複雜度的治理，則把它歸納為系統管理。

1. 需求和產品管理

從痛點入手，進行產研交付需求流程分析，進行解法歸納，落地工具保障需求的規範合理性執行。

圖5 需求和產品管理

2. 系統管理

以上已將需求和產品的問題進行規範化管理，那麼對於系統層面的問題和痛點要怎麼做呢？這裡面就進入了建模能解決的問題，只針對系統層面如何讓系統更好的支持業務。

3.3 建模面臨的挑戰

系統的挑戰：系統足夠複雜，接近6年的堆砌代碼老應用，集團戰略需求的重災區。組織的挑戰：團隊新組建，新的產研團隊，資料老舊且不全。沒有頭腦風暴的業產研溝通，還需要進行需求的日常交付。9個字表達就是抓重點，搞突破，擴全面。

圖6 建模面臨的挑戰

3.4 如何建模

以現代化企業架構思想為指導，構建業務架構元模型，進行業務、運營、組織和技術的整合，通過流程建模、領域建模、業務身份建模、能力建模進行業務架構的落地。

圖7 建模過程

3.4.1 流程建模

從業務運營規則入手，進行流程梳理，將業務邏輯和領域邏輯剝離開，以下圖為例，從用戶取消訂單到最後發起退款。

圖8 流程建模

在梳理運營規則的時候，其實已經是將業務流程還原的第一步，但此時要如何劃清業務邊界呢？可以通過介面契約進行隔離。再來看下圖就清晰許多，而業務邏輯和領域邏輯也進行了分離。

圖9 通過介面契約劃清業務邊界

從上面的流程來看其實可以發現有以訂單為主的申請、生產單為主的商家/倉儲、運單為主的配送、審核單的客服、賬單的退款。因此可以簡化下本模型，本模型只分為4個邏輯模塊，分別是解約申請、解約攔截（商家審核/倉儲攔截/配送攔截）、解約審核（客服審核/財務審核）、解約生效（財務退款），該模型就抽象的比較簡單了。

圖10 簡化後的模型

3.4.2 領域建模

構建一個解約單領域模型，來描述下通常會看到的"雞蛋"。首先將業務領域劃分為5個領域，除解約單外，就是上述流程建模中的四個核心子域，申請域、解約域、審核域、生效域。領域對象分為解約申請單、解約攔截單、解約審核單、解約生效單。

圖11 構建解約單領域模型的“雞蛋”

接下來統一業務語言，領域事件活動分析，進行領域服務拆解（這裡強調的信息內容與DDD的領域服務略有不同，更強調的是偏微觀，比如RPC介面緯度）。

圖12 通用語言表

接下來進行領域事件活動分析，併進行領域服務拆解，沉澱領域服務、領域能力、以及不同垂直業務的差異點進行擴展點抽離。

圖13 領域事件活動分析

圖14 領域服務拆解

借鑒優秀的nginx、asp.net 生命周期管理進行的業務流程設計，也與上述的方式比較相似。

圖15 業務流程設計

3.4.3 業務身份與數據建模

業務身份是針對不同業務方的唯一標識，分辨各個業務系統，業務身份分為垂直業務身份和水平業務身份。從業務目標來說：通過業務身份對不同的業務方需求進行業務邏輯隔離，中台以業務身份為主線賦能不同的業務方的各種定製化場景。從技術目標來看：系統運行期定位擴展點的核心依據，每個擴展點的實現與業務身份直接綁定。

明確垂直業務身份定義：能夠獨立提供商品或者服務，不依賴其他業務條線獨立展開經營活動，稱之為垂直業務。

明確水平業務定義：不能夠獨立提供商品或服務，必須依賴其他業務所包含的商品或服務，並且需要結合其他業務規則才能完成完整的經營活動。如秒殺、拼購等。水平業務是未來結構化表達中台沉澱的業務資產的方式。

明確場景定義：場景是垂直業務身份下更細粒度的業務邏輯隔離標識，在業務邏輯差異較少（技術層面上即擴展點有不同實現的數量較少）的情況下，可以使用場景做邏輯隔離，它的使用方式相比垂直業務更加輕量。

垂直業務和水平業務之間業務規則是可以疊加的，發生業務規則衝突時，需要判斷業務優先順序。而多個垂直業務之間的業務規則是不可以疊加的。一個業務完整規則由一個垂直業務規則+N個水平業務規則疊加而成。

圖16 垂直業務和水平業務

業務身份定義好後，進行數據模型映射，舉個例子，7鮮業務身份，自營業務身份來進行數據建模，通過垂直、水平、內核來定義。

圖17 數據模型映射

3.5 模型的驗證

建模以後，很多用戶比較苦惱的是模型是否與業務相吻合？再言之，模型是不是1:1的還原了真實的業務活動場景，那麼模型的驗證或者推演其實就是構建模型的核心。

無獨有偶，在快退中，由於筆者扮演多個角色、團隊負責人，架構師，還需承擔一線研發的需求評估，因此總結出了一套基於消息消息驅動的模型架構，還原了真實業務場景並指導研發的落地。

圖18 模型的驗證

四、B-PaaS化落地實踐

4.1 B-PaaS化工程架構指導

以PaaS化工程架構為基礎進行系統架構的升級改造：

圖19 系統架構的升級改造

如落地工程架構如下：

圖20 落地工程架構

4.2 實際需求案例落地PaaS化

4.2.1 業務流程分析

通過以B商城業務和C商城業務融合單據為點進行流程分析，分析圖如下，識別業務域、通用流程和可變點設計，從而輔助構建內核和擴展點的業務邏輯抽離。

圖21 業務流程分析圖

4.2.2 業務領域活動分析

領域事件拆解，識別領域對象、以及對應的業務子域，輔助研發進行業務和領域邏輯剝離。

圖22 業務領域活動分析圖

基於領域進行消息驅動開發，落地工程結構代碼映射，並通過核心域進行流程編排。

圖23 消息與領域映射

4.2.3 業務身份識別

通過藏經閣註冊的業務身份進行映射，找到對應本地的系統業務身份解析要素，進行業務ID的識別。

圖24 業務身份映射

圖25 識別業務ID

五、能力可視化

上節進行了B-PaaS化工程落地實踐，最終藉助藏經閣進行能力可視化上報，筆者項目是通過註解的方式進行上報。

圖26 能力可視化上報

圖27 上報配置&註解上報能力

六、總結

通過以上背景、產品、建模、工程化、可視化和實際需求落地B-PaaS工程的案例6個模塊，本文整體地介紹了快退平臺為什麼要進行PaaS化工程改造以及具體是如何實現的架構升級。希望通過本文，可以幫助讀者們對於訂單逆向履約系統有進一步的認識，同時期望給予讀者獨自面對複雜遺留系統時候，可以借鑒本文的架構升級改造思路，化解業務、系統複雜度，讓系統更高效的支持業務發展。此外，也歡迎讀者留言探討交流，是否遇到過複雜的遺留債務系統以及是如何解決的。

作者：京東零售 劉曉成

來源：京東雲開發者社區