DDD
領域驅動設計是一個有關軟體開發的方法論，它提出基于領域開發的開發模式，基于DDD理論，我們可以設計出高質量的軟體模型，
它圍繞業務概念構建領域模型來控制業務的復雜度，解決軟體難以理解和演化的問題，
微服務
微服務是一種架構風格，通過行程間通訊、容錯和故障隔離等方式，實作去中心化的服務治理，
DDD與微服務
它們都是高內聚、低耦合，從業務視角分離復雜度，提高回應能力，
高內聚：把相關的業務聚集在一起
低耦合：把關聯性較低的拆分為獨立的服務
使用DDD搭建微服務我們將獲得以下優勢：
- 設計清晰，規范
- 基于領域模型，有利于領域知識的傳遞和傳承
- 幫助團隊建立良好的溝通
- 協助系統架構的演進
- 提高團隊的設計能力（面向物件，架構）
設計
領域設計涉及技術與業務，如何讓它們協作起來呢？
戰略設計（業務）
領域、子域、限界背景關系
- 將領域拆分成子域，并劃分核心子域、支撐子域和通用子域
- 以子域展開事件風暴，根據背景關系語意劃分限界背景關系，建立通用語言，完成領域建模
- 領域建模將作為能力中心規劃的重要依據
- 完成能力中心地圖和優先級后，作為微服務設計的輸入完成戰術設計
戰術設計(技術)
聚合、聚合根、物體、值物件、領域服務等
-
按照領域模型完成微服務設計和落地
-
建立聚合、聚合根、物體、值物件、領域服務等物件之間的依賴關系，以代碼物件的形式映射到服務中，采用分層架構完成微服務設計和落地
分層架構可以采用Clean Architecture
DDD實踐程序
我們將通過DDD + Clean Architecture完成業務與技術的完整落地
統一語言（戰略設計）
統一：
- 領域模型術語
- DDD模式名稱
技術：
- 技術設計術語
- 技術術語
- 技術設計模式
業務：
- 領域模型術語
- DDD模式名稱
- 業務術語
- 設計無關的業務術語
事件風暴（戰略設計）
Event Storming是一種領域建模的實踐，可以讓領域相關人員快速理解業務模型
完整流程包括如統一語言、提出領域事件、規則、命令、讀模型、角色、劃分子域、票選、補充商機與價值等，
接下來我們先精簡一點步驟
活動準備
人：業務人員，領域專家，技術人員，架構師，測驗等
看板：可以將事件流可視化的白板或者畫圖工具等
彩色貼紙：填寫事件，命令等
業務場景
規定業務場景，下面我以一個電商專案為例
事件風暴結果
命令風暴結果
尋找聚合
聚合：一組相關領域模型的集合，盡量保證封裝業務的不變性，確保關聯關系緊密的領域模型內聚
- 按事件順序依次分析三個問題
- 事件改變的領域模型是什么
- 領域模型是否可以獨立訪問，是就是聚合
- 不能獨立訪問，需要通過哪個領域模型（聚合）來訪問，將其放到對應聚合內
- 命令貼在聚合左邊代表輸入，事件貼到聚合右邊代表輸出
- 檢驗是否符合聚合規則，不匹配的重新調整聚合
聚合結果
尋找聚合程序中可能會因為業務銜接產生新的輸入命令，以虛線表示
劃分限界背景關系
限界背景關系：某個場景或環境下的業務邊界
- 基于聚合和領域模型，判斷它們要解決的業務問題，如果是同一個問題則放到一個限界背景關系中，否則就拆分
- 如果一個聚合同時解決多個問題，則需要對聚合進行拆分，將拆分后的聚合劃分到不同的限界背景關系
- 解決的業務問題大小（變化原因，內在邏輯等）需與領域專家共同完成
限界背景關系結果
界限背景關系映射
當背景關系很多的時候，不同的團隊負責不同的背景關系，為了保證有效的作業可以定義不同的背景關系之間的關系來創建一個所有模型背景關系的全域視圖，兩個背景關系之間是有方向的，上游(U或Upstream)，下游(D或Downstream)
界限背景關系映射結果
子域
一個業務領域或子域是一個業務范圍，一個業務領域或子域可以包括多個業務能力，一個業務能力對應一個服務，
核心子域指業務成功的主要促成因素，是企業的核心競爭力，
通用子域被整個業務系統使用，
支撐子域是完成業務的必要能力，但不是成功的因素，
除了上面限界背景關系結果中標注的子域外，還可以擴展出財務，市場，采購等子域
領域物件關系（戰術設計）
分解聚合，提取該聚合包含的領域物件
- 領域物件的業務不變性
- 領域物件具有一致的生命周期
定義物體與值物件（戰術設計）
物體：存在唯一性標識，物體間是否相等的判斷依據也是唯一標識
值物件：表示屬性的不變值
以訂單聚合為例：
- 訂單聚合包含訂單物體，訂單行物體
- 訂單物體包含識訓地址值物件
架構設計
我們簡單的把架構設計看作是三個層面：
-
業務架構：根據業務需求設計業務模塊及其關系
DDD的領域建模其實就已經協助我們做了業務架構和系統架構
-
系統架構：設計系統與子系統的模塊及其關系
在DDD中業務架構是可以直接映射到系統架構上的
業務變化會演變為系統架構變化，影響到技術架構變化
-
技術架構：設計技術和框架細節
技術架構（微服務）則解決子系統之間的解耦，去中心化的服務治理和資料治理
Clean Architecture
尋找聚合時我們提到過輸入和輸出，而Clean Architecture與DDD集合后就非常適合作為采用DDD方法論的架構落地指導
為了更好的落地讀模型設計（查詢業務比較往往占八成以上），搭配CQRS可能是個不錯的選擇，
CQRS優勢在于職責分離，提高系統性能、可擴展性、安全性等，也可以從資料驅動轉為事件驅動，
要了解CQRS可以看第二篇 MASA Framework - EventBus設計
示例可以參考MASA EShop原始碼：https://github.com/masalabs/MASA.EShop
除了DDD以外，我們還提供了EventBus、Dapr、CQRS等多種實作方式
老系統演進
絞殺者模式
在現有系統外圍將新功能用新的方式構建為新的服務的策略，通過將新功能做成微服務方式，而不是直接修改原有系統，逐步的實作對老系統替換，采用這種策略，隨著時間的推移，新的服務就會逐漸“絞殺”老的系統，對于那些規模很大而又難以對現有架構進行修改的遺留系統，推薦采用絞殺者模式，
缺點：可能需要一段時間同時維護兩個或以上的專案
修繕模式
修繕者模式就如修房或修路一樣，將老舊待修繕的部分進行隔離，用新的方式對其進行單獨修復，修復的同時，需保證與其他部分仍能協同功能，從這種思路出發，修繕者模式更多表現為一種重構技術，
DDD實踐流程
總結
DDD雖然需要一定的學習成本，但掌握后既可以設計復雜的工程，也可以適當的縮減流程，在小型專案中直接以領域和聚合快速抽象領域模型，配合自己習慣的技術手段（如論是DB First還是Code First）來加強對系統設計的掌控力，
第一篇主要講解DDD在團隊中如何落地，而第二篇則是站在開發的角度如何落地，
學以致用，學無止境，
參考：
AWS領域驅動設計最佳實踐
領域驅動設計在互聯網業務開發中的實踐：https://tech.meituan.com/2017/12/22/ddd-in-practice.html
開源地址
MASA.BuildingBlocks：https://github.com/masastack/MASA.BuildingBlocks
MASA.Contrib：https://github.com/masastack/MASA.Contrib
MASA.Utils：https://github.com/masastack/MASA.Utils
MASA.EShop：https://github.com/masalabs/MASA.EShop
MASA.Blazor：https://github.com/BlazorComponent/MASA.Blazor
如果你對我們的 MASA Framework 感興趣，無論是代碼貢獻、使用、提 Issue，歡迎聯系我們
轉載請註明出處，本文鏈接：https://www.uj5u.com/net/424855.html
標籤：.NET技术
上一篇：如何在 Xamarin 中快速集成 Android 版認證服務 - 郵箱地址篇
下一篇：為定價表制作角落色帶粘性