微服務與領域驅動設計，架構實踐總結

怎樣的架構才能配得上造到飛起的變化？

一、軟件複雜性

1、複雜原因

如果軟件系統存在持續的迭代週期，那麼其中業務、技術、架構的複雜性都會直線拉昇，其相應的開發難度也會提高，可以用一句話總結其根本原因：唯一不變的就是變化；

應對複雜的變化一直都是軟件工程的核心難點問題，如何用較小的架構變化應對較大的業務變化，就是設計中常說的：高內聚、低耦合；還需要補充很重要的一點：單從技術層面是無法持續解決複雜問題的，還需要從管理角度去定義流程標準，規範各種解決方案，是整個部門要持續面對的事項。

2、應對複雜

不管是常說的設計模式、原則、面向對象，還是架構中常用的集羣、微服務、領域驅動等，都是在尋求更合理的方案來應對業務的變化；但是沒有一勞永逸的解決方法，既要做一定前瞻性的設計去預期業務，同時還要避免過度的設計影響業務進度；這就需要研發團隊具備一定的業務高度和技術深度：

在系統落地的過程中，需要對業務深入的分析和理解，不斷優化技術層面的解決方案；比如微服務的思想是通過拆分的手段實現業務塊之間的低耦合，領域驅動設計則實現各個業務邏輯的高內聚；下面圍繞兩種方式的實踐去詳細分析。

二、微服務架構

1、架構設計

系統的架構設計是一件極度複雜的事情，在工作的這幾年大致經歷過如下幾個階段：單服務、多服務集羣、微服務、持續集成；在近 2 年比較穩定的選型是微服務 + 自動化集成的模式：

思考其本質的變化邏輯，即爲了應對更復雜的業務體系；不管是業務拆分還是模型設計，都是在不斷實現高內聚低耦合的原則；降低業務之間的關聯影響，分離業務和技術的高度耦合。

2、業務場景

這裏先來看一個經典的業務場景：電商交易；基於微服務架構的電商交易場景中，通常至少會涉及如下幾個核心服務：交易、賬戶、訂單、商品、倉儲、物流；

站在業務角度，進行模塊化拆分和管理，結合持續集成的組件，通常可以輕鬆的應對各種複雜的業務場景，但是不存在真正意義上一勞永逸的手段，業務變化帶來的各種問題總會無腦推動開發去尋找更合理的解決方案；

在一次完整的電商交易場景中，實際上真正涉及到的微服務遠不止圖中的幾個，在 Trade 服務中交織關聯多個其他服務，在 MVC 的分層管理下，初期並不會存在較大風險，但是業務一旦經過多版升級改造之後，並且還存在版本兼容的要求，會給人一種極度混亂和不踏實的感覺；

如果團隊成員的綜合能力較高，並且版本有充足的時間去設計和優化，這種問題是可以妥善解決的，如果出現時間緊任務重的情況，隨之而來的壓力會持續在開發和測試之間來回橫跳；

解決過相關業務場景的研發都知道，重構加持續集成能力，結合嚴謹的測試，可以應對業務的不斷變化；但是在版本兼容的過程中，依然會導致工程中的代碼膨脹到飛起，特別是出現中場換人的情況，都會讓接手的人員在被埋和離開中，產生一次劇烈的心態掙扎。

3、問題分析

在 MVC 的架構模式中，工程通常會進行如下的分層管理：控制層、服務層、持久層、存儲層；服務層在特定複雜的場景中會做細化拆分，比如第三方對接、常用中間件的二次封裝：

對於在複雜業務線上爭渡的選手來說，對 Mvc 分層模式的缺陷是深有體會的，Service 層聚焦大量複雜的邏輯，通常核心業務塊中總會存在幾個代碼過千行的實現邏輯，不管用什麼思路和模式去拆分封裝，都很難解決該層不斷擴展帶來的膨脹問題。

4、面向過程

在 MVC 分層中，過程式的代碼極其明顯，通常以數據庫表和關係爲基礎，映射構建相關實體對象，這些實體對象並沒有具體的行爲和邏輯，只是作爲數據和結構的載體：

從面向對象中類的定義去看：屬性和行爲；而在 MVC 模式中，絕大多數實體都只是作爲數據的入參出參的結構定義，可以理解爲數據容器，在 MVC 的各層之間不斷搬運和加工。

三、領域驅動設計

相比 MVC 的分層設計，領域驅動設計 (Domain-Driven-Design 簡稱 DDD) 對於複雜業務系統的實現，提出了更加合理的解決方案，DDD 模式中涉及大量專業術語和抽象概念，可以參考EricEvans的相關書籍，本文只描述實踐中的核心概念。

1、分離模式

DDD 模型在分層設計上，劃分出核心的四層：接入層、應用層、領域層、基礎設施層；注意這裏只是單純站在服務端的常規架構角度去看，很明顯分離 MVC 模式中的服務實現層的邏輯：

其中領域層是關鍵所在，用來封裝複雜的業務，對應用層提供業務管理的核心支撐；整個模型也更具備縱向思維，有效的緩解單層複雜度過高的現象；單從模型設計上看，在工程中基於該分層去管理代碼包，也可以使每層的設計更加清晰和獨立。

2、設計思想

領域驅動設計並不是簡單的分層管理模型，涉及諸多抽象邏輯與專業術語，例如：領域、界限上下文、實體、聚合、值對象等等；

2.1 領域

領域可以理解爲業務場景中需要解決的問題合集，是具有範圍和邊界的約束；領域可以拆分多個子域，通常描述爲：核心域、支撐域、通用域：

關於子域的劃分也是參考業務屬性，可以把核心域理解爲最關鍵的業務場景，並且需要資源傾斜以應對其不斷的發展；支撐域可以理解爲相對穩定的業務；通用域偏向系統架構層面的公共能力；通過對領域的拆分實現業務分治，這與微服務的拆分思想相符合，兩種模式在業務角度是比較統一的；

2.2 界限上下文

DDD 中最晦澀難懂的一個抽象概念，特定模型的限界應用，不過可以借用原文的比喻會意一下：細胞之所以能夠存在，是因爲細胞膜限定了什麼在細胞內，什麼在細胞外， 並且確定了什麼物質可以通過細胞膜：

界限上下文的定義涉及粒度的思想，即每個粒度要具備獨立性；如上圖倉儲業務，可以將服務部署與倉儲子域、倉儲上下文做成一一對應的關係，或者在倉儲子域中分別定義：倉庫和貨架兩個上下文；這裏具有極大的靈活性，沒有真正意義上的標準可以參考。

2.3 映射關係

做好界限上下文的劃分，理清各個上下文之間的關係，明確業務場景中的依賴順序，這樣可以更好的推動開發流程的落地；對於上下文的關係描述也遠不止圖中的這些，還有共享內核、合作等等:

在上下文交互時，防腐層可以維護上下文的隔離和獨立，確保調用方不直接依賴服務提供方，從而實現不同上下文之間的依賴解耦；同時這也會帶來大量的對象轉換動作；

2.4 建模設計

子域和界線上線文完成對業務的拆分切塊，從而進行分治；基於防腐層降低各個界限上下文的耦合程度；聚合思想保證了業務問題的解決方案內聚；嚴格的分層模型實現服務支撐能力的分散；

領域模型的核心追求目標：高內聚、低耦合；更加抽象的、複雜的設計思想，也同樣意味着落地實現的難度更高，但不可否認領域模型作爲複雜業務的解決方案，邏輯上的確更加合理。

3、工程實踐

領域模型在代碼工程的實踐中，可以將不同的子域集成到各自的服務中，也可以在一個服務中，通過多個模塊 (Module) 進行隔離維護，即一個模塊對應一個界限上下文；

將業務問題進行分模塊分層分包的方式進行隔離，是代碼工程中的基本手段，這裏只是對組織方式進行描述，在實際的開發中，要根據依賴順序進行類庫拆包管理；

在程序的執行過程中，並不是所有的交互命令都需要經過領域層，實際上大部分業務中的查詢命令都是超過增刪改命令的，所以在純讀取數據的請求中，應用層可以繞開領域層直接訪問基礎設施層，減少一層數據處理邏輯。

四、實踐總結

最後來討論一些架構實踐的經驗，隨着技術的不斷髮展和更新換代，爲解決業務問題提供了極大的便利，不管是單服務中各種成熟的組件，又或者分佈式中的微服務體系，或者聚焦業務管理的領域模型；每種架構選型都有其適用的場景，不同的選型意味着不一樣的實現成本；

實際上在做架構選型時，成熟有經驗的主導者，都極其擅長做折中處理，也就是常說的退一步海闊天空；通常需要考慮團隊的綜合水平與業務需求和產品設計，當然在實際的協作流程中多方都是需要相對讓步的，但是對質量的要求以及核心業務的實現邏輯上是不能打折的。

五、參考源碼

編程文檔：
https://gitee.com/cicadasmile/butte-java-note

應用倉庫：
https://gitee.com/cicadasmile/butte-flyer-parent

作者：知了一笑

來源：知了一笑

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/mq9-lfFUutYepPY7M0OgkQ

猜你喜歡