前言
我們生活中都聽說了DDD，也瞭解了DDD，那麼怎麼將一個新項目從頭開始按照DDD的過程進行劃分與架構設計呢？
一、專業術語
各種服務
- IAAS：基礎設施服務，Infrastructure-as-a-service
- PAAS：平臺服務，Platform-as-a-service
- SAAS：軟件服務，Software-as-a-service
推薦一個開源免費的 Spring Boot 實戰項目：
二、架構演變
從圖中已經可以很容易看出架構的演進過程，通過對三個層的舉例來進行說明：
- SAAS：比如我們最早的就是單體應用，多個業務之間可能都沒有進行分層，之後我們業務多了，都各自混淆在一起，後來我們就通過MVC、SSM、分層等方式進行業務拆分，保證業務與業務之間解耦
- PAAS：隨者業務的增長，我們打算分離出一個子系統，但是成本太高，每次都需要從頭搭建一個子系統，效率低下。這時我們就抽取除了一些通用技術，比如mesh、SOA、微服務等方式來隔離系統，且對通用技術複用來快速搭建一個系統
- IAAS：比如訂單服務併發量高，單臺服務器已經無法滿足要求，這時我們需要多臺服務器，可能有windows的、linux、mac，想要快速部署就需要屏蔽OS，於是就有了VM、Docker、K8S等技術來屏蔽OS
三、限界上下文
限界上下文概念
BC與業務的關係：
通過對業務的劃分，比如訂單系統，訂單是一個子域；庫存是一個子域；其中商品再不同的子域中所表示的意義也不同，比如在訂單上下文中的商品表示商品的單價、折扣等等；而在庫存的上下文中商品表示商品的庫存量、成本、存放位置等。
BC與技術的關係：
多個子域之間必須需要在應用層進行聚合，而聚合的過程中就引出了技術方案，比如訂單到庫存到支付，他們應該採用同步方式；這幾個子域調用通知都應該是異步，那麼可能就需要消息中間件或其它技術方案
限界上下文劃分規則
一般來說，先考慮團隊規模，來決定最終需要劃分到多細粒度的BC，如果團隊規模過小而BC過細，則對後期的運維、部署、上線都會造成很大的負擔；在確定好粒度後，可以對語義相關性、功能相關性-業務方向、功能相關性-非業務方向進行劃分按照以上的規則劃分之後就得到了多個BC啦
一個BC代表一個微服務嗎？
概念： 微服務一般是指將高度相關功能的一個開發部署單元，有自己的技術自治性、技術選型、彈性擴縮容、發佈上下頻率等，說白了就是各自維護一個業務，然後多個業務組成一個系統，多個業務之間各自管理
關係： 這裏的BC其實就是一個領域或一個模塊或一個業務，如果兩個領域相關性很高，就可以包含多個BC，或者如果一個領域訪問量非常大，則需要部署在一個微服務中以提高性能
四、領域驅動設計的四重邊界
根據上圖所示，我們通過四重來進行架構設計：
分而治之：DDD通過規劃四重邊界，把領域知識做了合理的固化和分層。業務有核心領域和支持域、業務域中又拆分成多個限界上下文（BC），一個BC中又根據領域知識核心與否進行分層，領域層中按照多個業務（子域）的強相關性進行聚合成一個子域。
- 【第一重邊界】確定項目的願景與目標，確定問題空間，確定核心子領域、通用子領域（多個子領域可以複用）、支撐子領域（額外功能，如數據統計、導出報表）
- 【第二重邊界】解決方案空間裏的限界上下文就是一道進程隔離層面的物理邊界
- 【第三重邊界】每個限界上下文內，使用分層架構劃分爲：接口層、領域層、應用層、基礎設施層之間的最小隔離
- 【第四重邊界】領域層裏爲了保證各個領域的完整性和一致性，引入聚合的設計作爲隔離領域模型的最小單元
五、整潔分層架構
具體說明看圖中備註，總的來說就是通過實現與接口分離，讓domain層儘量獨立，而不耦合與任何模塊，這裏麪包含了領域模型的業務邏輯代碼，但不會依賴於具體技術實現，可以很方便更換基礎設施層，提供給第三方web調用service
六、六邊形架構
主動適配： 指來⾃於UI、命令⾏等輸⼊型命令， controller就是⼀種端⼝，端⼝的具體實現就是應⽤邏輯⾃身。因此端⼝和具體實現都在應⽤系統的內部。
被動適配： 指訪問存儲設備，外部服務等。每種訪問就是⼀種端⼝，具體實現是各個具體的中間件。因此端⼝在整個應⽤系統的⾥部，具體實現在系統的外部。每⼀種輸⼊和輸出都是⼀個端⼝，每個端⼝都有具體的實現邏輯，因此整個應⽤系統的架構就是⼀些列的端⼝+適配邏輯組成，架構圖就是⼀個多邊形形狀。有⼏個端⼝需要根據應⽤系統的具體情況⽽定，只是六個端⼝⽐較形象⽽得名爲六邊形架構。
特點：
- 外層依賴內層使得依賴更合理。端⼝就是接⼝，依賴接⼝編程。藉此保證了應⽤和實現細節之間的隔離。
- 可測試更好
七、洋蔥架構
洋蔥架構針對六邊形架構更進⼀步把內層的業務邏輯分爲了DDD概念的應⽤服務層、領域服務層和領域模型層。
特點：
- 圍繞獨⽴的領域模型構建應⽤
- 內層定義接⼝，外層實現接⼝
- 依賴的⽅向指向圓⼼（注意：洋蔥架構提倡不破壞耦合⽅向的依賴都是合理的，外層可以依賴直接內層，也可以依賴更⾥⾯的層）
- 所有的應⽤代碼可以獨⽴於基礎設施編譯和運⾏
總結
目前領域驅動設計是目前比較流行的一種架構設計，只需要按照領域驅動設計的四重邊界進行架構設計，就能夠很好的對各個領域解耦，對後期的業務垂直擴展、功能的水平擴展提供了良好的基礎。
版權聲明：本文爲CSDN博主「我思知我在」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。原文鏈接：https://blog.csdn.net/qq_32828253/article/details/110673205
更多文章推薦：
2.2,000+ 道 Java面試題及答案整理(2024最新版)
3.免費獲取 IDEA 激活碼的 7 種方式（2024最新版）
覺得不錯，別忘了隨手點贊+轉發哦！