如何理解領域驅動設計概念

本篇內容主要講解“如何理解領域驅動設計概念”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“如何理解領域驅動設計概念”吧!

Eric Evans 在2003年出版《領域驅動設計-軟件核心復雜性應對之道》，提出了DDD的軟件業務架構劃分方法論，成為如今微服務拆分的理論指導，而后Vaughn Vernon出版了《實現領域驅動設計》，以及后續極客時間、gitchat都有這方面的文章，不過都偏于理論，目前還未聽聞完全貫徹DDD思想的開源項目，一般都是以C#和Java作為案例。DDD并不想MVC一樣，大部分人都能劃分的非常明確，且相同。在我看來每個人理解DDD，結合實際項目都會根據技術架構、業務架構、領域驅動設計的理解，得出不一樣的領域劃分。

借用美團的文章：

現在的架構都是controller、service、dao、vo實體層。vo只是簡單的數據載體。簡單的業務系統采用這種貧血模型和過程化設計是沒有問題的，但在業務邏輯復雜了，業務邏輯、狀態會散落到在大量方法中，原本的代碼意圖會漸漸不明確，我們將這種情況稱為由貧血癥引起的失憶癥。領域驅動設計的充血模型就來限定模塊重要的domain所擁有的功能，并且規定基礎服務不能逆向調用上層方法。

1. 基本概念

DDD是對面向對象設計的改進，是開發復雜業務邏輯的一種方法。有利于指導應用程序分解為服務，每個微服務都有自己的領域。要靈活應用DDD來進行設計就需要知道他所提出的名詞及概念。

1. 1 領域domain、子域和限界上下文

領域：既可以表示為整個業務系統，也可以表示其中的核心域（core domain）或子域。

子域：領域下拆分的部分

限界上下文：子域是問題空間，限界上下文就是答案空間，不同子域在不同領域的含義是不一樣的。限界上下問就是給領域劃定邊界用的。

1.2 領域服務domain service、應用層

應用層：對應開發中的controller或API接口。

領域服務：處理領域的業務邏輯，實現不屬于實體或值對象的業務邏輯對象

1.3 聚合aggregate、聚合根 aggregate root、實體entity、值對象value object

聚合：領域中有多個聚合，是一個邊界內的領域對象的集群，由根實體和可能一個或多個其他實體和值對象組成，引用聚合必須通過表示

聚合根：應用中有唯一ID的類，根據識別出的聚合，包含實體與值對象。聚合中的對象生命周期都與聚合根一致，比如訂單和訂單明細，一般是1:n的關系，訂單作為聚合根，訂單刪了，訂單明細也掛了～

實體：內部擁有唯一ID，具有相同屬性的兩個實體仍然是不同的對象

值對象： 實體的屬性，或是值集合的對象，擁有相同屬性的值對象可以互換，比如值對象是money，由幣種和金額組成。相同的幣種和金額的money對象是可以對等的對象。

1.5 倉庫repository

用來訪問持久化聚合根的對象，簡單來說就是聚合根層面的CRUD。spring中與數據庫相關的類也是以repository結尾的。

1.6 基礎設施infrastructure

常用的工具類，底層數據庫持久化

1.7 工廠 factory

將聚合根生成的復雜過程放入工廠類中實現

2. 核心思想

領域驅動設計的核心思想明顯就是對于領域的劃分。領域中的事務也需要考慮

3. Java落地實現

有贊技術https://tech.youzan.com/dddclue/ 有一個相對完整的業務分析過程與落地實現。

有贊對包模塊是這樣劃分的

結合對項目淺顯理解，改造包結構為：

• infrastructure：里面放入了現有對dao層和util

• repository：save方法傳入聚合根，并且無返回值。具體如何將root拆解為vo對數據進行持久化在save中實現。

4. CQRS

CQRS（Command Query Responsibility Segration），命令與查詢職責分離，即讀寫分離，在代碼層面把讀寫分發到不同類中進行處理，讀取可以直接與數據庫進行交互。這個框架告訴你，即使CRUD也可以搞的很復雜。作為領域驅動設計發展而來的讀寫分離的技術架構，也有一套基礎組成元素

• command bus：將多個command 分發至對應的command handle中進行處理

• event source：事件溯源，保留聚合CRUD的歷史記錄，對于實現設計和監管的功能非常有幫助

• event bus：事件總線，異步將event寫入數據庫

• command handle：處理command

• query facade：查詢門面，將數據包裝為DTO，去除冗余屬性（如標識位、創建人等）

簡化了下讀寫分離模型，省去event bus這個消息組件。

實現簡單的CQRS

現有Axon框架按照DDD思想設計等CQRS框架。

5. 領域驅動設計并不是銀彈

目前市面主流方法論有

• OOA/OOD/OOP 面向對象的分析設計與方法，通常用UML進行建模描述

• ER建模，即數據驅動開發，根據業務設計數據庫表結構進行開發

• DDD 領域驅動設計

• 四色建模，由The Open Group制定，在1995年發表TOGAF架構框架。分為四個元素組成（1）時刻-時間段原型（Moment-Interval Archetype）、（2）參與方-地點-物品原型（Part-Place-Thing Archetype）（3）描述原型（Description Archetype）（4）角色原型（Role Archetype)
  國內很少公司會嚴格遵循領域驅動設計方法論，高學習成本，往往很難得其精髓。實際上往往根據業務和團隊情況，使用E-R圖、UML、DDD的某些概念，取幾種方法論核心部分進行業務架構分析設計。 主流MVC架構的確做到了視圖、業務、數據的解耦，但是其中的VO是貧血模型（只有屬性和對象的get、set方法），業務代碼的編寫也面向過程化。 領域驅動設計中說道：該模式只適合用于業務足夠復雜及多變，若是簡單的業務邏輯，強行套用DDD反而會過度設計，造成簡單問題復雜化，違背了DDD實際讓復雜業務簡單化的初衷。

6. 總結

領域驅動設計的優缺點都非常明顯。

缺點

• 學習成本、團隊意識要求，需要對業務高度抽象

• 需要領域專家與技術人員拉通統一領域語言，耗時大，與現在流行的Scrum敏捷開發相背離

• 業務變化的復雜性，需要識別多變業務進行領域建模，出現“缺乏設計”與“過度設計”

優點

• 合理的應用方法論，可以對系統進行抽象，解耦

• 復雜業務分治

如何使用

1. 首先判斷業務是否足夠復雜多變，相對穩定建模

2. 劃分領域、限界上線文等基礎部件

3. 合理將子領域分給不同微服務進行開發 總之，優秀的設計都是經過大量的與業務進行磨合迭代才產生的，如何界定復雜度和領域還是要與領域專家進行交流。 參考書籍及資料有～《微服務架構設計模式》、《軟件架構設計-大型網站技術架構于業務架構融合之道》、領域驅動設計兩本神書、我段的思想、有贊的技術博客。

到此，相信大家對“如何理解領域驅動設計概念”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！