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

一、軟體複雜性

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 映射關係

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

• 上下游(U-上游，D下游)：描述上下文調用時的關係，服務調用方為D，服務提供方為U；
• 防腐層(Anticorruption-Layer，簡寫ACL)：上下文交互時封裝的一層，提供對動作的校驗、適配、轉換等；
• 開放主機服務，發佈語言(Open-Host-Service簡寫OHS，Published-Language簡寫PL)：定義訪問協議；

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

2.4 建模設計

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

• 防腐層(Anticorruption-Layer)：上下文交互時封裝的一層；
• 領域層(Domain-Layer)：在分層架構中負責領域邏輯的設計和實現；
• 領域服務(Domain-Service)：行為無法識別歸屬的實體時，封裝到領域服務；
• 聚合(Aggregate)：相關對象的集合，描述核心領域，通常把聚合作為數據修改的單元；
• 實體(Entity)：通過標識來定義的對象，而不是基於屬性，比如Uid標識用戶實體；
• 值對象(Value-Object)：描述特征或屬性但沒有標識的對象；
• 工廠(Factory)：封裝對象複雜的創建邏輯與類型；
• 存儲庫(Repository)：把存儲、緩存、搜索等資源封裝的機制，對應領域模型；

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

3、工程實踐

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

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

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

四、實踐總結

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

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

五、參考源碼

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

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