在DDD的專案實踐中，我們會使用一些常用的架構模式，來進行系統架構的合理設計，
以下是DDD常用架構模式：
- DDD分層架構
-
整潔架構
-
六邊形架構
-
DDD分層架構 vs 整潔架構 vs 六邊形架構
-
Event Driven 架構
-
CQRS(Command Query Responsibility Segregation) 架構
-
微服務內領域事件設計模式
-
微服務間領域事件設計模式
DDD分層架構
DDD 分層架構包含用戶介面層、應用層、領域層和基礎層，
分層架構的一個重要原則是每層只能與位于其下方的層發生耦合，
分層架構可以簡單分為兩種，即嚴格分層架構和松散分層架構，在嚴格分層架構中，某層只能與位于其直接下方的層發生耦合，而在松散分層架構中，則允許某層與它的任意下方層發生耦合，
分層架構的優點，Martin Fowler在《Patterns of Enterprise Application Architecture》一書中給出了答案：
- 開發人員可以只關注整個結構中的某一層，
- 可以很容易的用新的實作來替換原有層次的實作，
- 可以降低層與層之間的依賴，
- 有利于標準化，
- 利于各層邏輯的復用
適當的分層體系結構將開發層面進行隔離，這些層不受其他層的更改的影響，從而使重構更加容易，劃分任務并定義單獨的層是架構師面臨的挑戰，當需求很好地適應了模式時，這些層將易于解耦或分層開發，
使用場景：
- 需要快速構建的新應用程式
- 需要嚴格的可維護性和可測驗性標準的應用
整潔架構
整潔架構又名“洋蔥架構”，整潔架構的層就像洋蔥片一樣，它體現了分層的設計思想，在整潔架構里，同心圓代表應用軟體的不同部分，從里到外依次是領域模型、領域服務、應用服務和最外圍的容易變化的內容，比如用戶界面和基礎設施，
整潔架構最主要的原則是依賴原則，它定義了各層的依賴關系，越往里依賴越低，代碼級別越高，越是核心能力，外圓代碼依賴只能指向內圓，內圓不需要知道外圓的任何情況，
在洋蔥架構中，各層的職能是這樣劃分的：
- 領域模型實作領域內核心業務邏輯，它封裝了企業級的業務規則，領域模型的主體是物體，一個物體可以是一個帶方法的物件，也可以是一個資料結構和方法集合，
- 領域服務實作涉及多個物體的復雜業務邏輯，
- 應用服務實作與用戶操作相關的服務組合與編排，它包含了應用特有的業務流程規則，封裝和實作了系統所有用例，
- 最外層主要提供適配的能力，適配能力分為主動適配和被動適配，主動適配主要實作外部用戶、網頁、批處理和自動化測驗等對內層業務邏輯訪問適配，被動適配主要是實作核心業務邏輯對基礎資源訪問的適配，比如資料庫、快取、檔案系統和訊息中間件等，
- 紅圈內的領域模型、領域服務和應用服務一起組成軟體核心業務能力，
六邊形架構
六邊形架構又名“埠配接器架構”，
六邊形架構的核心理念是：應用是通過埠與外部進行互動的，
六邊形架構將系統分為內六邊形和外六邊形兩層，這兩層的職能劃分：
- 紅圈內的六邊形實作應用的核心業務邏輯；
- 外六邊形完成外部應用、驅動和基礎資源等的互動和訪問，對前端應用以 API 主動適配的方式提供服務，對基礎資源以依賴倒置被動適配的方式實作資源訪問，
DDD分層架構 vs 整潔架構 vs 六邊形架構
三種微服務架構模型的對比和分析
- 雖然 DDD 分層架構、整潔架構、六邊形架構的架構模型表現形式不一樣，但這三種架構模型的設計思想正是微服務架構高內聚低耦合原則的完美體現，而它們身上閃耀的正是以領域模型為中心的設計思想
- 架構模型通過分層的方式來控需求變化從外到里對系統的影響，從外向里受需求影響逐步減小，
- 面向用戶的前端可以快速回應外部需求進行調整和發布，靈活多變
- 應用層通過服務組合和編排來實作業務流程的快速適配上線，減少傳導到領域層的需求，使領域層保持長期穩定，
事件驅動架構（Event Driven Architecture - EDA）
事件驅動架構 (Event-driven architecture) 是一種軟體架構模式，對于事件驅動系統而言，事件的捕獲、通信、處理和持久保留是解決方案的核心結構，這和傳統的請求驅動模型有很大不同，
許多現代應用都采用了事件驅動設計，因為事件驅動本身是一種編程架構方法，而不是一種編程語言， 因此事件驅動應用可以用任何一種編程語言來創建，事件驅動架構可以最大程度減少耦合度，因此是現代化分布式應用架構的理想之選，
事件驅動架構采用松散耦合方式，因為事件發起者并不知道哪個事件使用者在監聽事件，而且事件也不知道其所產生的后續結果，
可以從兩個方面來理解 EDA：
- EDA 是一種側重于以生成/消費為基礎的異步通信的架構模式，這主要對照于傳統的基于執行緒的同步系統，
- EDA 是一種以事件 (event)為核心，提供事件產生，路由，消費已經結果回呼等機制的架構模式，
介紹一個保險承保業務程序中有關領域事件驅動架構的例子，
一個保單的生成，經歷了很多子域、業務狀態變更和跨微服務業務資料的傳遞，這個程序會產生很多的領域事件，這些領域事件促成了保險業務資料、物件在不同的微服務和子域之間的流轉和角色轉換，
在下面這張圖中，列出了幾個關鍵流程，用來說明如何用領域事件驅動設計來驅動承保業務流程，
CQRS(Command Query Responsibility Segregation) 架構
命令查詢的責任分離Command Query Responsibility Segregation (簡稱CQRS)模式是一種架構體系模式,能夠使改變模型的狀態的命令和模型狀態的查詢實作分離，
本質上，CQRS是一種讀寫分離的機制
兩種實作方式：
2. CQ兩端資料庫和上層代碼都分離，然后Q的資料由C端同步過來，一般是通過Domain Event進行同步，同步方式有兩種，同步或異步，如果需要CQ兩端的強一致性，則需要用同步；如果能接受CQ兩端資料的最終一致性，則可以使用異步，
微服務內領域事件設計模式
微服務間領域事件設計模式
領域事件處理包括：事件構建和發布、事件資料持久化、事件總線、訊息中間件、事件接收和處理等
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/264818.html
標籤：其他