如何形成統一設計風格-實踐篇

一背景

在上一篇《業務團隊如何統一架構設計風格？》中，探討了一種業務架構的設計規範，以期達到這些目標：用標準約束技術細節；用技術工具而非文件推行標準；持續重構而非造新輪子；重視業務建模。但通篇表述較為抽象。本篇將總結團隊近來的架構演進工作，以更具體的技術細節，詳細闡釋該理念，作為“統一業務設計風格”的實踐篇。文中詳述了多個層面的設計規約和基於規約的搭建方式，並在末尾回答了上一篇的諸多疑問。

二總覽

上圖以電商產品為例，展示了一套標準框架的各層設計單元。先簡單瞭解下概念，下一章節會詳細解釋各層的設計規約和搭建方式：

產品模式層

以產品合約描述完整的功能列表；以簽署人身份來定位產品功能的適用場景；以合約分組來描述一個獨立完備的功能域，分組的集合就是產品功能的範圍和邊界。透過對合約分組進行組裝，可以快速搭建商業產品。

業務模型層

為了減少不同技術同學對領域進行建模的風格差異，我們對業務模型的使用場景做了諸多約定，串聯起倉儲管理/業務流程/業務元件等基礎模組。所有人更關注於業務在模型上的表達，而大大減少了對實現細節的關注。基於對領域的分析，可以快速搭建業務模型。

業務流程層

用一套標準的業務流程框架，描述業務模型的完整執行流程：業務元件是一套高內聚的業務功能集合，基於元件配置將業務模型的資訊適配為標準引數，交由基礎設施執行具體功能；流程引擎負責建立和管理流程例項，接收指令來觸發元件動作的執行，並實現狀態推進/條件跳轉和異常處理等分支管控的需求。透過對業務元件/基礎設施的抽象和沉澱，可以快速搭建業務流程。

資料檢視層

用一套標準的資料流機制，來滿足檢視層的定製化需求：資料流訂閱器用於採集資料，物理來源包含區塊鏈跨鏈資料/業務DB資料/檔案系統資料/離線任務資料等；資料流消費器用來加工原始資料，生成展示層資料/待核對資料/資料指標等等。訂閱器確保了資料來源的穩定和低成本的快速接入，消費器則交由技術同學自行定製業務邏輯。在不干擾領域建模的基礎上，可以快速搭建資料檢視。

三規約詳解

1 產品模式

產品合約

1）規約

產品合約以全域性視角，描述完整的業務模式，包括：服務的目標客戶，依賴的業務領域，輸出的服務等等

產品合約的內容是一份靜態描述檔案，需要由簽署身份列表來界定使用場景

2）例項

以電商產品為例，商家單獨簽署的產品合約被作為商家合約，描述了商品的上架要求；商家+平臺+買家共同簽署的產品合約，則適用於交易下單場景。

3）搭建

新增/修改低程式碼：基於業務需求，在產品中心設計產品模板，明確合約分組和具體內容

使用：接入時編碼，一次性：在業務系統內編寫對應產品合約和簽署身份的模型類，完成和產品中心的對接，包括合約的建立/失效，基於簽署身份的合約查詢等等

合約分組

1）規約

合約分組以區域性視角，描述某個高度內聚的業務領域所提供的功能和依賴的配置資訊，包括：業務模型，業務服務，業務流程，業務元件等等

多個合約分組共同組成一個可交付業務的產品合約

2）例項

電商產品合約下，商品分組描述了商品上架的流程和配置，下單分組約束了訂單建立的流程和服務資訊，退貨分組則說明了退貨流程和買家能夠享受的客戶服務。

3）搭建

新增/修改低程式碼：以元資料的方式定義一個合約分組，包含模型/流程/配置等等，每一個配置都可以用鍵路徑/配置值型別和限制等描述

使用硬編碼：在業務系統內定義合約分組的模型類，完成與產品合約內容互動的寫入和讀取，在業務程式碼處顯式獲取業務分組例項低程式碼：搭建合約查詢->分組解析->配置獲取的通用框架（引入快取避免重複查詢），業務層只需要透過元資料描述，就可以獲取對應分組內的配置資訊

2 業務領域

模型

1）規約

業務模型描述一個領域內的核心業務實體，是唯一貫通業務流程和業務元件的業務例項

一個業務模型內可以關聯其他模型，但應避免出現迴圈依賴

一個完備的業務模型描述需要包含：資料模型，檢視模型，業務模型/資料模型/檢視模型的三者轉換，業務模型倉儲等

2）例項

退貨業務，基於退貨單推進業務流程，各業務元件從退貨單獲取必要的業務資訊，執行退貨/退款/通知等業務功能；退貨單關聯自一個正向訂單，但正向訂單不可反向依賴退貨單；一個退貨單模型對應一張主單據表和多張退貨明細表，倉儲需要負責完成業務模型<->資料模型的雙向讀寫

3）搭建

硬編碼：編寫業務模型（Model）/資料模型（DO）/資料互動（Mapper）/檢視模型（VO）/轉換層（Converter）/倉儲（Repository）等等

低程式碼：用元資料描述，自動生成DO/VO/Mapper/Converter；基於底座提供的倉儲元件，也可以透過元資料描述，自動生成業務模型倉儲的例項

服務

1）規約

1、業務服務是一套以業務領域為單位（interface）作聚合，開放給內外所有使用方的最小業務功能單元（method）

2、業務服務需要一套定義規範（annotation/aop等），對每一個功能單元有清晰直觀的元資料描述，用以實現服務發現/文件生成/許可權管控/穩定性保障等等。元資料包括：業務域，業務動作，讀/寫，錯誤碼範圍，返回值模型等等

3、業務服務的入參，限制為一個sysParam和一個bizParam，前者為呼叫來源/冪等ID/產品碼/租戶ID等系統引數，後者為各業務自行定義的模型引數，建議為可全鏈路透傳（rpc->api->flow->component）的POJO

4、業務服務以Result形式返回，錯誤碼儘量控制在元資料描述的範圍內，不洩漏任何exception給呼叫方。返回的業務資訊，建議為POJO或VO

5、業務服務不侷限於呼叫方的物理來源，只需要在對接層增加簡單的轉換邏輯，做授權管控即可

6、寫服務的實現，需要有事務管理機制

2）例項

public interface DemoOrderService { /** * 下單申請 * @param sysParam sysParam * @param bizParam bizParam * @return result */ @ApiFunction（apiType = ApiType。SUBMIT， funcBiz = “ORDER”，funcAction = “APPLY”， returnType = OrderApplyResponse。class， errorCodeType = CommonErrorCodeEnum。class） CommonResult apply（ApiReqSysParam sysParam， OrderApplyInfo bizParam）；}

3）搭建

新增/修改定義-低程式碼：基於元資料描述，自動生成interface+method+errorcode+POJO等等

實現硬編碼：簡單需求/不可模板化/無法流程化的業務需求，直接編碼低程式碼：對於標準的流程發起服務（申請上架/申請下單/申請退貨），用模板實現合約分組載入->流程配置載入->流程初始化（冪等）->流程觸發->結果處理；對於標準的流程推進服務（通知回執/排程推進），用模板實現流程配置載入->流程觸發->結果處理等等。隨著更多服務場景的出現，可以有更多模板化的業務服務。

使用硬編碼：與所有interface的使用一樣，組裝請求->呼叫->處理結果低程式碼：基於元資料描述和業務配置，將當前業務物件/外部引數對映為服務入參的POJO，異常處理模板化，成功返回的結果以同樣方式映射回業務物件或外部響應

流程

1）規約

1、Flow用於描述一個完整的業務流程，基於單個業務模型，推進一個或多個業務子環節

2、對於單個業務模型的同一型別業務流程，可以有多個Flow定義，以滿足不同業務模式的定製需求

3、Flow包含遷轉（transition），元件（component）和動作（action）三級結構，運作原理如下：每次觸發（operate）對應於元件的一次action，所有action都成功的component會完結，而所有component都成功的transition將會觸發Flow和業務模型的狀態遷轉。

4、Flow的目標是將複雜流程拆解成多個原子化的業務動作，相互解耦

5、Flow需要結合業務服務/訊息/排程等呼叫入口的觸發，才能實現完備的流程推進

6、Flow需要依賴外部呼叫方提供事務管理機制（通常是業務服務），需要依賴業務模型倉儲來控制模型的載入和儲存

2）例項

3）搭建

新增/修改低程式碼：Flow自身的運作由底座元件支撐，只需一次性編碼；若需要定義業務流程，可基於業務元件模板和業務模型，動態生成Flow配置檔案；加上版本控制和隔離機制，就可以防止相容性問題

使用硬編碼：Flow初始化場景，從當前業務領域的合約分組中，獲取需要的Flow配置，初始化流程並推進；Flow推進場景，基於modelId+modelType+operate+request，可以用模版化程式碼自動觸發低程式碼：透過對合約分組中Flow配置的標準化，可以將Flow初始化場景也以模板化的方式實現；當一個現有業務服務需要支援新定製的業務流程時，只需調整合約內的配置即可

元件

1）規約

1、業務元件是某一類業務動作的聚合，面向業務功能設計，不侷限於任何一個業務模型

2、業務元件的業務動作，是原子化的最小業務單元，粒度暫無強制要求，但以解耦和複用程度為衡量依據；建議其依賴一個到多個基礎設施/業務服務，以模板化的方式提供標準的業務動作實現

3、對於某個業務模型，業務元件透過開放介面卡（詳見【基礎設施-適配】）的方式支援受控定製，或以完全複寫的方式實現排他定製（不允許其他業務複用）

4、所有的核心業務邏輯，都應收歸到業務元件層及其以下（無流程的簡單業務服務除外），包括但不限於：引數校驗，業務校驗，重入/冪等控制，業務模型變更，合約分組變更，計算規則，外部服務互動等等

5、業務元件需要一套定義規範（xml/annotation等），對其支援的業務動作和業務模型有清晰直觀的元資料描述，用以搭建業務流程。元資料包括：業務動作列表和對應的觸發點（operate），支援的業務模型列表

2）例項

核身元件定義類

public interface BizModelDiscountComponent extends BizModelComponent { /** * 佔用優惠 * @param context */ void occupy（FlowContext context）； /** * 退回優惠 * @param context */ void refund（FlowContext context）；}

核身元件元資料配置

核身元件模板化實現

介面卡Adapter的解釋，詳見【模型適配】小節

public abstract class AbstractBizModelDiscountComponent< T extends BizModel> implements BizModelDiscountComponent< T> { @Resource private DiscountApiService discountApiService； @Override public void occupy（FlowContext context） { // TODO AdapterConfigInfo根據context從當前合約中獲取 T bizModel = （T） context。getBizModel（）； getDiscountAdapter（）。processOnOccupyResult（ bizModel， discountApiService。occupy（getDiscountAdapter（）。toOccupyInfo（bizModel， new AdapterConfigInfo（））））； } @Override public void refund（FlowContext context） { // TODO AdapterConfigInfo根據context從當前合約中獲取 T bizModel = （T） context。getBizModel（）； getDiscountAdapter（）。processOnRefundResult（ bizModel， discountApiService。refund（getDiscountAdapter（）。toRefundInfo（bizModel， new AdapterConfigInfo（））））； } @SuppressWarnings（“unchecked”） protected BizModelToDiscountAdapter< T> getDiscountAdapter（）{ return （BizModelToDiscountAdapter< T>） FlowInstanceFactory。instanceBizAdapter（ “DISCOUNT”，（Class< ？ extends BizModel>） TypeUtils。getRealClassOfParameterizedType（this））； }}

3）搭建

新增/修改硬編碼：全新業務元件基本無法低程式碼化，需要開發有足夠的設計思維和大局觀，權衡複用度和成本後實現初版；隨著業務發展，逐步抽象出模板化的業務元件實現；很多場景下，如果避免不了複雜的定製邏輯，可以自行以策略/職責鏈/工廠等多種設計模式落地，這依賴於開發者的建模能力，不做強制要求低程式碼：已有的業務元件應用於新業務模型的場景，如果已經抽象出合約配置+介面卡+基礎設施的標準模板，只需做合約配置即可（通知/核身/存證上鍊等場景適合）

使用低程式碼：在Flow底座中完成業務元件的編排/發現和觸發，一次性編碼；完成Flow配置，即完成業務元件的裝配

3 基礎設施

注：此處的基礎設施與DDD中的概念有很大差異，請勿混淆

規約

基礎設施是一套以高複用高內聚低變化的外部服務能力為單位（interface）作聚合，開放給業務服務/業務元件使用的最小功能單元（method）

基礎設施可以是對渠道能力的封裝，如外部商家渠道服務/跨境渠道服務等；也可以是對通用技術能力的封裝，如優惠服務/商品服務/客戶服務等

基礎設施和業務服務的差異在於：前者的核心功能通常由外部服務提供，在當前系統內的核心職責是引數組裝/場景識別/返回解析和異常處理

基礎設施的定義不依賴於外部服務，入參為自行定義的標準POJO，返回值同樣以Result封裝，遮蔽外部服務的exception和業務異常，業務返回同樣是標準POJO

例項

基礎設施-資訊通知

public interface NotifyGateway { /** * 通知（郵件/簡訊/站內信） * @param notifyInfo * @return */ CommonResult notify（NotifyInfo notifyInfo）；}

搭建

新增/修改硬編碼：基礎設施的接入通常是一次性的，低程式碼的價值不易發揮

使用硬編碼：在業務服務/業務元件等呼叫方程式碼中，組裝入參->呼叫->解析返回低程式碼：在業務元件中，基於下文將介紹的適配機制，可以實現：合約配置+模板化業務元件，低程式碼複用現有基礎設施

4 模型適配

規約

模型適配用於銜接業務模型和基礎設施/業務服務，實現模型->入參和返回->模型的雙向處理

在模板化的業務元件中，介面卡和基礎設施/業務服務的呼叫鏈已經固化，各業務模型的元件例項只需要實現對應的介面卡，即可完成業務定製

介面卡通常與產品合約配置結合，描述業務模型->基礎設施/業務服務入參的對映關係

例項

介面卡-業務模型->網銀簽名

public abstract class BizModelToDiscountAdapter< U extends BizModel> implements BizModelAdapter< U> { @Override final public String getType（）{ return “DISCOUNT”； } /** * 生成扣減申請 * @param bizModel * @return */ abstract public OccupyInfo toOccupyInfo（U bizModel， AdapterConfigInfo configInfo）； /** * 處理扣減結果 * @param bizModel * @param result */ abstract public void processOnOccupyResult（U bizModel， CommonResult< OccupyResponse> result）； //。。。}

訂單模型Order，需要使用優惠扣減服務時，需要實現介面卡BizModelToDiscountAdapter：

@BizAdapterpublic class OrderToDiscountAdapter extends BizModelToDiscountAdapter< Order> { @Override public List< ConfigDef> getConfigDefs（） { return Lists。newArrayList（ ConfigEnum。DISCOUNT_TYPE， ConfigEnum。DISCOUNT_TERM ）； } @Override public OccupyInfo toOccupyInfo（Order bizModel， AdapterConfigInfo configInfo） { // 解析出客戶選擇的優惠型別 return new OccupyInfo（）； } @Override public void processOnOccupyResult（Order bizModel， CommonResult< OccupyResponse> result） { // TODO 根據扣減成功的優惠，重新計算訂單金額 } // 。。。}

搭建

新增/修改定義-硬編碼：當業務元件和基礎設施/業務服務出現呼叫關係時首次定義，通常不再變更實現-低程式碼：可以用一套靈活的合約配置描述對映關係，實現一次編碼後只需配置維護；但是，這既依賴於DSL級別的描述能力，也需要業務模型和基礎設施/業務服務的設計者，都具備較高的抽象能力，成本較高

使用硬編碼：當業務開發抽象出可模板化的業務元件時，即完成了首次接入；當基礎設施/業務服務出現新模式時，需要進行適配調整

四總結

囉嗦了這麼多，為避免被過度細節沖淡主題。最後以幾個問題做個小結：

1 業務設計規範體現在哪裡？

架構層面，從產品合約->業務領域->基礎設施，我們對應用做了模組拆解，在不同層面設計了業務規約，約束了各模組的職責；技術層面，透過多個底座元件，一定程度上實現了平臺和業務定製的隔離，限制了業務細節的無序散佈。

2 業務設計只有合適沒有標準，為何要強制規範？

規範的目的不是標準本身，本文提出的標準也未必適合所有問題域。想傳達的是，團隊內需要有業務設計的某種共識和沉澱，在每次迭代需求和每次專案產出的基礎上，持續積累持續重構持續最佳化，這對新人融入/個人成長和團隊協作都很有幫助。

3 如何快速支撐業務，研發效能提升體現在哪裡？

需要明確的是，對於全新的業務需求，不會帶來明顯的效能提升，甚至會為了滿足設計規範，帶來一定程度的額外成本。但當多人協作，工作交接，或是現有功能部分可複用的場景下，會減少很多不必要的溝通和維護成本。舉例來說，當一個業務需求出現時，研發人員需要做如下判斷：

業務模型：是否需要新的業務模型，是否需要調整現有模型