[[439211]]

一 背景

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

二 總覽

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

• 產品模式層

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

• 業務模型層

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

• 業務流程層

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

• 數據視圖層

用一套標準的數據流機制，來滿足視圖層的定制化需求：數據流訂閱器用于采集數據，物理來源包含區塊鏈跨鏈數據/業務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<OrderApplyResponse> 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)實例

<?xml version="1.0" encoding="UTF-8"?> 
 
<flow id="OrderApply" version="001" desc="標準下單流程"> 
    <config> 
        <model class="xxx.xxx.Order"/> 
    </config> 
    <init type="INIT" desc="初始化"> 
        <action operate="INIT.INIT"/> 
    </init> 
    <transitions> 
        <transition from="INIT" to="ITEM_OCCUPIED"> 
            <component type="ITEM" desc="扣減庫存"> 
                <action operate="ITEM.OCCUPY"/> 
            </component> 
        </transition> 
        <transition from="ITEM_OCCUPIED" to="DISCOUNT_OCCUPIED"> 
            <component type="DISCOUNT" desc="扣減優惠"> 
                <action operate="DISCOUNT.OCCUPY"/> 
            </component> 
        </transition> 
        <transition from="DISCOUNT_OCCUPIED" to="SUCCESS"> 
            <component type="NOTIFY" desc="下單成功通知"> 
                <action operate="NOTIFY.SELLER"/> 
                <action operate="NOTIFY.BUYER"/>               
            </component> 
        </transition> 
    </transitions> 
</flow> 

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<T extends BizModel> extends BizModelComponent<T> { 
 
    /** 
     * 占用優惠 
     * @param context 
     */ 
    void occupy(FlowContext context); 
 
    /** 
     * 退回優惠 
     * @param context 
     */ 
    void refund(FlowContext context); 
} 

• 核身組件元數據配置

<componentTemplate type="DISCOUNT" desc="優惠"> 
    <interface name="xxx.xxx.BizModelDiscountComponent"/> 
    <bizModelMappings> 
        <bizModelMapping> 
            <bizModel class="xxx.xxx.Order"/> 
            <componentEntry name="orderDiscountComponent"/> 
        </bizModelMapping> 
        <bizModelMapping> 
            <bizModel class="xxx.xxx.RefundOrder"/> 
            <componentEntry name="refundOrderDiscountComponent"/> 
        </bizModelMapping> 
    </bizModelMappings> 
    <triggerMappings> 
        <triggerMapping> 
            <triggerTemplate operatePostfix="OCCUPY"/> 
            <methodEntry name="occupy"/> 
        </triggerMapping> 
        <triggerMapping> 
            <triggerTemplate operatePostfix="REFUND"/> 
            <methodEntry name="refund"/> 
        </triggerMapping> 
    </triggerMappings> 
</componentTemplate> 

• 核身組件模板化實現

適配器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<NotifyResponse> 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：

@BizAdapter 
public 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 如何快速支撐業務，研發效能提升體現在哪里?

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

• 業務模型：是否需要新的業務模型，是否需要調整現有模型
• 業務服務：xxxxxxxxxxxx業務服務，xxxxxxxxxxxx現有服務
• 業務流程：xxxxxxxxxxxx業務流程，xxxxxxxxxxxx現有流程
• 業務組件：xxxxxxxxxxxx業務組件，xxxxxxxxxxxx現有組件
• 基礎設施：xxxxxxxxxxxx基礎設施，xxxxxxxxxxxx現有設施
• 產品合約/合約分組：基于上述判斷，評估產品合約和合約分組的組裝

 

帶來的效能提升有這樣幾點：業務領域的每個模塊互相解耦，研發過程并行化，投入人員1+1可以=2;改造范圍更易于定位，資源評估更為準確，進度把控更加清晰;針對頻繁變動且成本過高的模塊，進行針對性的重構，影響范圍可控;上文中的很多處規約，都有潛在的低代碼化可能，能進一步提升搭建效率。