怎樣的架構才能配得上造到飛起的變化？
一、軟體復雜性
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
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/464089.html
標籤：其他
上一篇：行為型：十一. 解釋器模式