開發複雜業務系統，有哪些設計思路

最近參與了一些電商業務中臺等複雜業務系統的設計和開發，結合DDD和中臺等，

有一些架構方面的思考和體會，在這裏記錄一下。

 

 

作技術方案，核心是下面幾個問題：

• 作什麼？- 產品需求

• 業務上怎麼作？- 業務文檔

• 技術上怎麼作？- 技術方案

• 代碼怎麼實現？- 落地實現

明確了這幾個問題，能夠處理大部分平常需求開發，若是是比較複雜的業務系統，就須要拆解的更精細。

好比電商的商品管理、訂單交易、促銷活動營銷中心等系統的開發和重構，業務相對複雜，開發人天在幾個月以上，直接開發可能會老虎啃天，無從下手。

 

這時候能夠經過一個流程化的模板來指導，若是抽象一個通用的流程，能夠參考下面的套路：

• 業務拆解 > 複雜度來源 > 核心挑戰點 

• 領域驅動設計 > 業務過程分析 > 領域模型抽象 > 模型分解

• 分層組織 > 工程架構 > 模塊化 > 組件化

• 考慮功能複用 > 可選路徑 —（ 業務身份，能力，擴展點，工做流程，編排）

• 方案產出 >  總體-模塊-流程-細節 > 方案評審 > 最終方案

 

其中的功能複用環節，是包括阿里在內的大部分業務中臺的解決思路，僅供參考。

 

1、業務拆解

1.1 複雜度來源

爲何要關注複雜度？

 

我比較認同系統設計中「軟件複雜度」的觀點，架構設計的目的是爲了解決軟件系統的複雜度帶來的問題，因此在設計架構時，首先就要分析系統的複雜度。

 

只有正確分析出了系統的複雜性，後續的架構設計方案纔不會偏離方向；

不然，若是對系統的複雜性判斷錯誤，即便後續的架構設計方案再完美再先進，都是南轅北轍，作的越好，錯的越多、越離譜。

 

舉個例子，醫院管理應用的醫療管理系統（HIS），複雜度在於業務邏輯複雜，系統之間調用不清晰，

若是你設計一個QPS幾萬的高性能架構，就是沒有解決系統的核心問題。

 

正確的作法是將主要的複雜度問題列出來，而後根據業務、技術、團隊等綜合狀況進行排序，優先解決當前面臨的最主要的複雜度問題。

 

 

1.2 核心挑戰點

 

射人先射馬，擒賊先擒王。

 

肯定了複雜度，也就肯定了系統設計的難點，在進行系統設計時，能夠把難點列出來，各個擊破。 

以優惠券爲例，促銷活動最大的複雜度來自營銷形態的變化，營銷最大的不變就是變，亂花漸欲迷人眼，各種促銷方式變幻無窮。

每次促銷活動都有不一樣的玩法和定義，促銷系統的設計必須對促銷模式有所抽象，任何活動或優惠手段都是基於最基本的促銷模式而創建的。

 

電商促銷活動和優惠券建設難點包括：

• 底層模型抽象：底層模型抽象能夠經過DDD的方式，對領域模型和進行抽象。

• 促銷引擎性能：性能問題如何解決？已是老生常談，工程領域有不少經典的解決方案，好比緩存，異步，最終一致性。

• 關聯繫統交互：理清和關聯繫統的交互

 

2、領域驅動設計

軟件系統的目的反映在業務上，都是來解決一系列問題，例如考試系統完成考試，電商就是賣貨，

 

同一個領域的系統都具備相同的核心業務，由於他們要解決的問題的本質是相似的，一個領域本質上能夠理解爲一個問題域 。

 

只要肯定了系統所屬的領域，那麼這個系統的核心業務，即要解決的關鍵問題就基本肯定了。

 

任何一個系統都會屬於某個特定的領域，例如論壇系統，核心功能是肯定的，好比用戶發帖，回帖等基本功能。

 

廣義的電商系統也是一個領域，作電商業務，必需要支持的商品，訂單，交易，物流等功能。

 

2.1 領域模型設計

 

DDD裏有領域專家的概念，領域專家要在這個領域深刻研究，只有這樣纔會遇到很是多的該領域的問題，積累比較更加豐富的經驗。

一般來講，一個領域有且只有一個核心問題，也就是核心子域。在覈心子域、通用子域、支撐子域梳理的同時，會定義出子域中的限界上下文及其關係，用它來闡述子域之間的關係 。

 

以電商營銷爲例，優惠券、抽獎、套餐等，都是圍繞這個促銷這個業務範圍來進行的，在促銷域以外，還有相關的用戶、商品、訂單、風控、商家等。

 

 

3、架構分層

3.1 架構分層

下圖是領域驅動設計中經典的分層架構：

 

 

 

 

用戶界面/展現層：

• 請求應用層獲取用戶所需的展現數據；

• 發送命令給應用層執行用戶的命令

應用層：

薄薄的一層，定義軟件要完成的任務。

對外爲展現層提供各類應用功能，對內調用領域層（領域對象或領域服務）完成各類業務邏輯。應用層不包含業務邏輯

 

領域層：

表達業務概念、業務狀態信息及業務規則，是業務軟件的核心

 

基礎設施層：

爲其餘層提供通用的技術能力，提供了層間通訊；爲領域層提供持久化機制。

 

這是一個相對簡單的分層架構，其實已經老生常談，那麼問題來了，咱們在上面拆解的領域模型，如何映射到更加複雜的工程架構中？

  

3.2 工程架構

DDD的核心訴求就是將業務架構映射到系統架構上，在響應業務變化調整業務架構時，也隨之變化系統架構。 

微服務追求業務層面的複用，設計出來的系統架構和業務一致，不過領域模型並不直接反映數據結構，須要明確這一點。

領域驅動設計最後落地到數據存儲上，不須要直接參考領域模型，在最後的技術架構上能夠自由選擇合適的技術架構。

 

 

 

 

  

3.3 模塊組織

Java項目通常是典型的Maven多模塊項目，可使用不一樣的Module，區分各個層次，進一步，經過Package來控制DDD中的限界上下文。

 

 

 

3.4 領域對象

對具體的領域對象封裝時，典型的有充血和貧血模型，因爲大部分程序員習慣在Service裏封裝業務邏輯的貧血模型，徹底的充血模型開發效率相對較低，

我本身的體會是，技術服務業務第一，在開發時能夠靈活的選擇實現策略，模型對象封裝一些簡單的靜態方法，大部分業務邏輯仍是放在領域服務中實現。

 

 

4、考慮功能複用

4.1 編程DRY原則

你們都知道，編寫整潔代碼，有一個很是重要的原則就是DRY，

Don't Repeat Yourself，避免產生重複代碼，有經驗的程序員都可以意識到這一條約束。

 

若是你使用Idea開發，Idea也會識別而且提示你重複的代碼，建議你進行抽象。

DRY的好處更少的代碼是好的，它節省了時間和精力，易於維護，而且減小了bug的概率。

除了在軟件開發領域，在業務系統層面，也存在如何避免重複能力建設，考慮業務複用的問題。

 

 

 

 

 

4.2 業務層面的DRY

業務系統層面的DRY原則，其實能夠總結爲一個問題，就是複雜業務系統，如何實現具備共性的業務能力的複用，這個也是不少業務中臺關注的問題。

通常的，大部分業務中臺（特指業務中臺，不包括數據中臺等其餘形態）對業務複用的方式，

均可以經過定義業務身份 ——>  梳理擴展點 ——> 枚舉業務能力 ——> 根據不一樣業務身份編排工做流 ——> 實現業務能力複用，這樣的流程來實現。

 

能夠對比編程中的Pipeline模式，或者責任鏈模式，只不過每一個鏈條上負責處理輸入和輸出的，是不一樣的業務功能。

 

業務中臺是另外一個話題，這部分是發散思考，具體能夠參考阿里巴巴 TMF （Trade Mudule Framework）框架的介紹：

如何實現32.5萬筆/秒的交易峯值？阿里交易系統TMF2.0技術揭祕

 

 

5、可擴展性和過分設計如何平衡

好的架構設計必定是擴展簡單的。

在設計時，要儘可能封裝可能的變化，在業務流程發生一些調整時，可以比較方便地修改系統程序模塊或組件間的調用關係而實現新的需求，也就是咱們常說的可擴展性。

可是可擴展性自己也是系統設計的複雜度來源之一，這就涉及到一個問題，如何平衡可擴展和過分設計。

 

5.1 區分肯定性和變化

好的架構必定是擴展簡單，運行平穩的。

系統架構最開始能夠從一個通用的流程開始，case-by-case，

而後將「變化少」的部分沉澱下來爲架構，將「變化多」的沉澱爲擴展或者配置，梳理清楚，將這二者結合起來，最後完成系統架構設計。

 

5.2 用容量規劃的方式來處理擴展程度

可使用容量規劃的思想，來處理可擴展性設計。

在作技術方案時，容量規劃是一個特別重要的環節，要預估將來幾年的增加量，進行數據庫和緩存的容量規劃。

我以爲這個方式也能夠應用在擴展性設計上，對業務變化進行預期，考慮技術方案可以支持的業務發展時間。

 

6、方案評審

好的技術方案很難一蹴而就，大部分時候要通過反覆的調整，就是須要關聯的各方參與方案的評審和修改，最終肯定最終技術方案。

個人建議是，團隊最好輸出一份技術方案的規範，能夠供每一個成員參考，從設計階段，就統一團隊成員的認識。

 

 

7、總結

最後再總結一下，關於複雜業務系統開發的一些體會：

1. 熟悉業務，抽象產品需求，分析相關測試用例，瞭解各類用戶角色和其使用的場景

2. 自頂向下進行方案設計，對於比較複雜的業務系統，比較好的方式是先關注頂層模型，避免在一開始就陷入技術和業務細節中去

3. 從總體設計，到模塊局部規劃，設計好部署架構、分層和分模塊、API設計、數據庫設計等

4. 能夠參考成熟的解決方案，好比將開源軟件，改造，變成適合本身業務需求的架構

5. 驗證和優化架構設計方案，完整的架構設計方案，須要有屢次的評審，充分收集各方面的反饋，反覆修改後肯定

6. 合理進行擴展，考慮架構預期能知足多長時間的業務增加，好比將來一年的業務變化