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

一、軟件復雜性

1、復雜原因

如果軟件系統(tǒng)存在持續(xù)的迭代周期，那么其中業(yè)務、技術、架構的復雜性都會直線拉升，其相應的開發(fā)難度也會提高，可以用一句話總結其根本原因：唯一不變的就是變化；

• 業(yè)務變化：導致復雜性的根本原因，在多端多版本適配的過程中代碼快速膨脹；
• 數(shù)據(jù)變化：數(shù)據(jù)隨著業(yè)務的變化和發(fā)展，不斷沉淀積累，需要做橫向與縱向的管理；
• 技術升級：技術組件可能因為漏洞，或者更好的解決問題，不間斷升級版本；
• 人員變動：模塊的開發(fā)人員一旦出現(xiàn)流動，換人接手會給代碼帶來風格上的差異；
• 心態(tài)起伏：持續(xù)應對復雜問題，但平穩(wěn)的心態(tài)很難持續(xù)，也是人員流動的一個因素；

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

2、應對復雜

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

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

基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權限、多租戶、數(shù)據(jù)權限、工作流、三方登錄、支付、短信、商城等功能

• 項目地址：https://github.com/YunaiV/ruoyi-vue-pro
• 視頻教程：https://doc.iocoder.cn/video/

二、微服務架構

1、架構設計

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

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

2、業(yè)務場景

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

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

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

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

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

3、問題分析

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

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

4、面向過程

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

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

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權限、多租戶、數(shù)據(jù)權限、工作流、三方登錄、支付、短信、商城等功能

• 項目地址：https://github.com/YunaiV/yudao-cloud
• 視頻教程：https://doc.iocoder.cn/video/

三、領域驅動設計

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

1、分離模式

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

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

2、設計思想

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

2.1 領域

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

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

2.2 界限上下文

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

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

2.3 映射關系

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

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

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

2.4 建模設計

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

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

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

3、工程實踐

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

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

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

四、實踐總結

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

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

五、參考源碼

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

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

審核編輯 ：李倩