公司來了個新同事,把 DDD 運用得爐火純青!

Java技术栈發表於2024-04-25

前言

我們生活中都聽說了DDD,也瞭解了DDD,那麼怎麼將一個新專案從頭開始按照DDD的過程進行劃分與架構設計呢?

一、專業術語

各種服務

  • IAAS:基礎設施服務,Infrastructure-as-a-service
  • PAAS:平臺服務,Platform-as-a-service
  • SAAS:軟體服務,Software-as-a-service

推薦一個開源免費的 Spring Boot 實戰專案:

https://github.com/javastacks/spring-boot-best-practice

二、架構演變

從圖中已經可以很容易看出架構的演進過程,透過對三個層的舉例來進行說明:

  • 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就是⼀種端⼝,端⼝的具體實現就是應⽤邏輯⾃身。因此端⼝和具體實現都在應⽤系統的內部。

被動適配: 指訪問儲存裝置,外部服務等。每種訪問就是⼀種端⼝,具體實現是各個具體的中介軟體。因此端⼝在整個應⽤系統的⾥部,具體實現在系統的外部。每⼀種輸⼊和輸出都是⼀個端⼝,每個端⼝都有具體的實現邏輯,因此整個應⽤系統的架構就是⼀些列的端⼝+適配邏輯組成,架構圖就是⼀個多邊形形狀。有⼏個端⼝需要根據應⽤系統的具體情況⽽定,只是六個端⼝⽐較形象⽽得名為六邊形架構。

特點:

  1. 外層依賴內層使得依賴更合理。端⼝就是接⼝,依賴接⼝程式設計。藉此保證了應⽤和實現細節之間的隔離。
  2. 可測試更好

七、洋蔥架構

洋蔥架構針對六邊形架構更進⼀步把內層的業務邏輯分為了DDD概念的應⽤服務層、領域服務層和領域模型層。

特點:

  • 圍繞獨⽴的領域模型構建應⽤
  • 內層定義接⼝,外層實現接⼝
  • 依賴的⽅向指向圓⼼(注意:洋蔥架構提倡不破壞耦合⽅向的依賴都是合理的,外層可以依賴直接內層,也可以依賴更⾥⾯的層)
  • 所有的應⽤程式碼可以獨⽴於基礎設施編譯和運⾏

總結

目前領域驅動設計是目前比較流行的一種架構設計,只需要按照領域驅動設計的四重邊界進行架構設計,就能夠很好的對各個領域解耦,對後期的業務垂直擴充套件、功能的水平擴充套件提供了良好的基礎。

版權宣告:本文為CSDN博主「我思知我在」的原創文章,遵循CC 4.0 BY-SA版權協議,轉載請附上原文出處連結及本宣告。原文連結:https://blog.csdn.net/qq_32828253/article/details/110673205

更多文章推薦:

1.Spring Boot 3.x 教程,太全了!

2.2,000+ 道 Java面試題及答案整理(2024最新版)

3.免費獲取 IDEA 啟用碼的 7 種方式(2024最新版)

覺得不錯,別忘了隨手點贊+轉發哦!

相關文章