業務團隊如何統一架構設計風格？

簡介：首次上線應用，面對業務框架搭建你是否曾感到無從下手？維護線上應用，面對大量歷史包袱你是否正避坑不及深陷泥潭？爲什麼一樣是業務應用，不一樣人的設計風格千差萬別？爲什麼最初的設計通過多個迭代後老是面目全非？新人來到團隊，怎樣才能快速瞭解業務，不被大量技術細節折磨？若是你也有這些困擾，但願本文能提供些許幫助。

做者 | 木沉
來源 | 阿里技術公衆號

首次上線應用，面對業務框架搭建你是否曾感到無從下手？維護線上應用，面對大量歷史包袱你是否正避坑不及深陷泥潭？爲什麼一樣是業務應用，不一樣人的設計風格千差萬別？爲什麼最初的設計通過多個迭代後老是面目全非？新人來到團隊，怎樣才能快速瞭解業務，不被大量技術細節折磨？若是你也有這些困擾，但願本文能提供些許幫助。

一 初衷

1 細節割裂架構

業界的成熟應用框架有不少。不管是SpringMVC/SpringBoot仍是SofaBoot，都對工程結構給出了明確的規範約定，職責邊界看似很是清晰。但在實踐中，再簡單的業務應用都避免不了業務邏輯分散各處，打破module邊界出現隱式耦合的現象。分散的業務細節必然致使應用架構的割裂，若是沒有持續的重構調整，最終總會變得複雜臃腫（固然，是持續有新需求的前提下），老人沉默新人流淚，只能依靠天降猛男重作2.0。究其緣由，我的認爲主要在於：

• 框架靈活性太高：應用框架給出的是工程規範，而非業務設計規範，爲開發者保留了很是大的靈活性，一個業務功能能夠有不少種實現方式。
• 架構約束力不足：業務架構的搭建和維護是在不一樣時段由不一樣人分別投入的結果，設計思惟的不一樣，自我要求的不一樣，項目進度壓力的不一樣，都會對應用的現狀產生影響。

若以法律和道德的關係作類比，通用框架約束了技術編碼的「法律」底線，而設計原則就是開發人員對自身的「道德」要求。在簡單的業務場景下，知足需求是第一優先級，設計能力的訴求並不突出。但在多方協做的業務團隊下（真實狀況大多如此），沒有統一的「道德標準」，將很難造成協力完成複雜項目。《Java開發手冊》（阿里巴巴Java開發規約）在推動編碼標準的道路上邁出了很大一步，極大提高了工程人員的專業素質，大大提升了「道德共識」。那麼在業務架構設計的領域裏，是否至少能在某個問題域內，也創建一套面向業務研發同窗的「設計規約」。

2 技術沉澱流失

另外一方面，進入阿里巴巴後，自身研發經歷雖然並很少，但接觸過很多優秀設計。這些產出不管是否最優方案，都體現出了技術同窗對優秀設計的美好願望和強大落地能力，也確實在必定的歷史時期內高效地保障了業務發展。然而，令我困惑的是，儘管每一個業務項目和業務產品都能沉澱出一些可複用的組件或框架，參與研發的同窗也能總結出一套面向將來需求的設計原則和實踐經驗，但這些財富始終難以維護和傳承。可能的緣由有（對前端/測試/數據/平臺等研發經歷不太瞭解，這裏僅針對一線業務研發）：

• 堅持設計成果而非設計原則：有成功經驗的研發同窗，傾向於用曾經的架構設計來套用當下的業務場景。這種思路自己沒有對錯，但若是釘不配錘，每每會在短時間內引入大量額外成本，反倒喪失了本來的設計優點。面對具體問題域，只有堅持一向的設計原則，在需求分析的過程當中結合諸多因素進行動態權衡，才能打造真正符合當下和將來需求的設計。
• 喜歡造新輪子而非持續重構：研發同窗的設計原則和代碼潔癖多是一種「玄學」，對前人代碼的不待見卻是更具肯定性的常態，其實這不難理解。即便都是DDD流派，方案溝通時也未必互相承認；即便通過讓步對架構設計達成一致，編碼實現的風格也是各領風騷。理解前人的設計思路和代碼癖好更重要，仍是按時完成業務需求更重要？按本身擅長的設計風格重寫更簡單，仍是在他人的「過期」設計上持續重構優化更簡單？
• 靠文檔傳承而非工具化複用：對新人來講，文檔裏的再多建議和快速上手指南，都比不上一個開箱即用的工程DEMO；在成熟應用上持續開發的人，不會由於歷史文檔上大寫的注意事項就抵抗住臨時代碼換取早點下班的現實誘惑，除非應用工程中有編譯/部署失敗的強制約束讓你不得不放棄。

相比於缺乏「設計規約」致使的低效協做，已經沉澱的「規約原型」被輕易拋棄更加使人惋惜。業務研發的平常工做，本質上是拆解問題域的複雜性，用分層解耦/工具化/平臺化/業務抽象的多種思路將子問題逐個擊破。若是部分子問題已被很好解決，爲什麼不站在前人肩上？放棄造不造新「輪子」的糾結心態吧，或許咱們更須要搭「積木」的心態。

二 思路：業務架構設計規約

結合螞蟻鏈-應用技術團隊近年來的技術實踐，咱們試圖從自身需求出發，搭建一套或許能知足更多業務場景的業務架構設計規約。重點說明下，本文是從有限的問題域出發提出的解決思路，不奢求成爲通用解決方案。若是其餘業務線也有相似的痛點，但願能有些許借鑑。

• 標準：統一業務設計框架，用標準化架構簡化技術細節
• 沉澱：從業務場景中持續沉澱「積木」
• 重構：持續重構「積木」，減小重複建設
• 集成：基於業務服務編排引擎快速集成

1 標準——減小細節

理想狀況下，業務技術只需關注領域建模，但現實中卻不得不考慮更多通用的技術細節。以供應鏈金融場景下簡化版的應收帳款發行流程爲例，須要考慮的有：

• 領域建模：應收帳款領域模型及其行爲的設計
• 流程編排：流程模型的設計及發行流程的狀態機設計
• 數據轉換：領域模型<->數據模型及流程模型<->數據模型的雙向轉換
• 併發控制：業務鎖機制的設計
• 業務冪等：流程中各業務環節的冪等控制
• 異常處理：異常捕捉，錯誤碼約定
• 監控報警：摘要日誌，異常日誌，邊界日誌
• 其餘

在以上未徹底列舉的幾項中，除了「領域建模」之外，基本都是與具體業務無關，但對於一個穩定可靠的業務應用不可缺失的部分。若是能創建一套標準化的框架方案，用統一的規範解決掉業務無關的大量細節，是否就能讓業務技術同窗真正的專一於「領域建模」？

2 沉澱——能力複用

沉澱和複用是技術羣最常出圈的幾個詞，可見認同度之高。能力複用不侷限於形式和粒度，可以切實下降技術成本，提升業務擴展性，就是不錯的沉澱，可做爲「積木」供後續使用。以螞蟻鏈應用技術團隊場景爲例，近年來沉澱的能力包括但不侷限於：

技術類

• 工程規範系列：約束編碼規範和邊界接口定義風格，日誌打印，異常處理，倉儲行爲，狀態機等等
• 讀寫分離機制：屏蔽交易類需求與查詢類需求對數據模型的設計衝突，下降設計複雜性，提高查詢性能和靈活性

業務類

• 網銀核身：提升網銀核身簽名在不一樣業務流程中的擴展性
• 合約上鍊：提升智能合約對接在不一樣業務流程中的擴展性

平臺類

• 配置中心：靈活定義和管理業務流程須要的各種配置項
• 產品中心：平臺功能打包和隔離，實現業務流程的全局視圖

3 重構——持續優化

沉澱來源於業務需求，卻經常落後於新需求。對於設計者之外的人來講，維護他人的「積木」經常會踩到很多坑，反倒不如本身重寫。這也是爲什麼每一個團隊都在說沉澱，但可以橫向複用，甚至在同一個團隊內持續複用的能力都少之又少。雖然這個現象沒有完美解法，但我的建議採起以積極的心態看待這些「積木」：

• 分析歷史背景，瞭解「積木」出現的技術和業務背景
• 明確該能力可以解決的問題，和不適用的場景
• 分析當下業務需求，是否能夠重構該能力後直接複用
• 與創做者溝通，評估重構落地方案

這裏沒有強調重構複用和重寫這兩種方案的ROI對比，是由於我的看來，即便前者成本更高，重構的過程對我的技術成長和團隊文化統一都是有利的。相對於不斷推翻和發明新「積木」，持續優化的過程，是對本身和他人經驗的不斷回顧和反思，看清歷史的坑，才能避免新風險的出現。

4 集成——靈活搭建

標準可以落地，除了有足夠趁手的「積木」庫外，更重要的一點，是要有靈活便捷的「粘合劑」，以完成業務功能的快速搭建和靈活調整。在供應鏈金融的場景下，業務需求主要體現爲各類各樣的業務流程，好比發行/轉讓/清分等等。爲了簡化「積木」搭建，靈活複用底層能力，咱們基於如下目標，設計了面向業務的服務編排引擎：

• 標準化：遵循設計規約，將業務無關的通用技術細節屏蔽
• 插件化：對「積木」友好，可持續沉澱和複用新能力
• 業務化：面向業務，有業務描述能力的流程編排
• 配置化：經過配置便可完成流程編排，最好能作到可視化配置

5 產品——業務大圖

「積木」+「粘合」可以知足技術落地的低成本高擴展，但從業務視角，還須要一個全局大圖來描繪業務線的全域能力和功能流程。本文中暫不涉及。

三 實踐——業務架構標準方案

如前所說，只靠文檔造成的共識，對技術沒有足夠的約束，極難維持。所以，咱們基於上述規約的各項原則，搭建了一套標準化的業務架構設計方案，經過組件化工具化的方式約束業務應用，造成團隊共識。一個標準的業務應用架構以下：

1 組件——規範技術細節

經過組件化約定，約束通用技術細節的行爲，包括但不侷限於：

交易模型

描述業務流程的核心交易模型，用於管控狀態推動，維持與業務模型的關聯。

倉儲行爲

數據持久層的通用行爲，包括鎖定查詢/插入/更新/普通查詢等。

事務模板

定義事務邊界，確保模版內業務邏輯的事務一致性；支持冪等能力。

通用業務模板

定義業務邏輯邊界，無事務性保障，但包含了異常處理/日誌埋點等通用能力。

通用查詢模板

定義查詢邏輯邊界，與通用業務模板相似，但主要面向單項/批量/分頁等查詢場景。

消息

對消息中間件的簡單封裝，適配業務應用規約，下降配置成本。

調度

對調度中間件的簡單封裝，適配業務應用規約，下降配置成本。

服務開放

api組件規範對外服務能力，經過註解識別服務定義和服務實現，自動生成接口文檔，描述接口參數/返回/業務域/錯誤碼等等。

其餘——日誌/異常處理/請求參數/返回類型

這裏不作展開。

以上是全部業務應用都會遇到的技術細節，用組件屏蔽細節的思路也沒有複雜之處，咱們想要表達的重點是：儘量沉澱和複用技術組件，儘量使用他人的成果，不要重複搭建，把重心放到業務上！

2 領域——專一業務建模

再次強調，對業務技術來講，業務建模是核心，業務建模是核心，業務建模是核心！本文的初衷和方案都是爲了讓開發解放出來，直面核心業務的設計和思考。本小節僅給出領域產出的基本要求，後續在【案例分析】再作詳述。

領域實體

建模的核心是抽象出領域實體及其關聯關係，不一樣的業務場景和設計思路，會有很大差別，最終會體現爲一到多個領域模型。須要明確在不一樣業務流程下，各交易模型內須要包含的領域模型（比較抽象，後續在【案例分析】再作詳述）。

領域倉儲

定義數據模型，及其與領域模型的對應關係（各類converter）。基於上文提到的倉儲組件，配置數據庫表和鏈接，實現鎖定查詢/插入/更新/普通查詢等業務行爲。

領域服務

基於業務行爲，抽象出原子化的領域服務能力。該服務無需關注數據倉儲，無需關注業務流程，僅抽象出領域實體的原生能力。以上文中提到的應收帳款模型爲例，至少須要包含：

• 應收帳款的建立
• 應收帳款的拆分/流轉
• 應收帳款的銷燬

等等基本行爲。

交易實體

用於承載交易流程的業務實體，上文中交易模型的業務實例，內部關聯一到多個領域實體。

交易倉儲

用於管控交易實體以及內部各領域實體的倉儲行爲。

3 服務編排引擎 —— 積木+粘合

但凡涉及複雜業務流程的應用，都須要引入流程引擎來編排狀態機的流轉。業界有不少成熟的流程引擎框架，也有不少足夠可用的簡化版本。但如前文所說，這類通用引擎的優勢也是其最大的弱點：過強的靈活性沒法對設計風格造成約束，大量業務細節會分散在不一樣狀態節點間，不直觀也難維護。從自身需求出發，咱們設計了面向業務的服務編排引擎，以遵循業務設計規約的方式約束技術，以直觀的形式描述業務流程。與傳統流程引擎相比，其業務友好性主要體如今：

• 約束業務模型：需明確指定業務交易模型/狀態及倉儲定義，遵循業務設計規範
• 託管倉儲行爲：只需配置業務模型及倉儲實現，無需再關注數據持久化的時機和細節
• 編排領域服務：經過轉接層，將領域服務開放到引擎中自由編排。領域的原子能力是引擎編排的最小執行單位
• 靈活增減狀態：流程中的狀態遷轉和業務行爲都可被靈活插拔
• 支持「積木」擴展：將可複用的領域服務組合打包，造成固定模式，做爲「積木」在其餘流程中重複使用

總的來講，服務編排引擎基於通用組件屏蔽技術細節，重點專一於業務行爲的編排和複用，對「積木」進行「粘合」，以編排出符合業務需求的業務流程。

四 總結

本文從業務技術團隊的現實痛點出發，嘗試以業務架構設計規約（理論標準）結合業務架構標準方案（工程約束）的思路統一團隊的技術風格，將技術同窗從細節中釋放出來，專一於技術能力的積累和對業務價值的思考。但願傳達的想法有：

• 用標準約束技術細節：下降業務設計的靈活性，也是爲了減小成本
• 用技術工具而非文檔推行標準：持續沉澱的組件，賽過沒有約束力的文檔
• 持續重構而非造新輪子：正視本身和他人曾經的產出，持續改進能帶來成長
• 重視業務建模：好好思考業務和行業吧，用DDD武裝本身，提高建模思惟和能力

篇幅所限，【案例分析】後續另開一篇再作詳述。文中一些不成熟的想法，也歡迎多多指正。

---

阿里雲開發者社區

世界讀書日，來讀書吧

4月23日是第26個世界讀書日，阿里雲開發者社區推出「記錄閱讀之路，影響同行之人」活動，6位阿里技術人爲同窗們分享他們看過的好書，開發者藏經閣也推出了最受你們歡迎的電子書。

點擊連接：https://developer.aliyun.com/topic/worldreadingday?utm\_content=g\_1000264434，推薦曾經影響你的書，來一塊兒讀書吧~

本文內容由阿里雲實名註冊用戶自發貢獻，版權歸原做者全部，阿里雲開發者社區不擁有其著做權，亦不承擔相應法律責任。具體規則請查看《阿里雲開發者社區用戶服務協議》和《阿里雲開發者社區知識產權保護指引》。若是您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將馬上刪除涉嫌侵權內容。