領域驅動設計(Domain-Driven-Design)是一種針對大型復雜系統的領域建模與分析方法論。

2003 年，Eric Evans 發布《Domain-Driven Design: Tackling Complexity in the Heart of Software》(領域驅動設計：軟件核心復雜性應對之道)，其中定義了DDD。

DDD改變了傳統軟件開發針對數據庫進行的建模方法；DDD先對業務領域進行分析，建立領域模型，根據領域模型驅動代碼設計。合理運用面向對象的高內聚低耦合設計要素，降低整個系統的業務復雜性，并使得系統具有更好的擴展性，更好的應對多變的業務需求。

領域 Domain

一個領域就是一個問題域，只要是同一個領域，那問題域就相同。

只要確定了系統所屬的領域，那么這個系統的核心業務，即要解決的問題以及問題的邊界就基本確定了。

舉例

陌生人社交領域，包含有聊天，用戶推薦，朋友圈等核心環節。 只要是這個領域，一般都會有這些相同的核心業務，因為他們要解決問題的本質是一樣的，就是交友。

每一個領域，都有一個對應的領域模型，領域模型能夠很好的幫我們解決復雜的業務問題。

驅動設計

在DDD中，以領域(domain)為邊界，分析領域的核心問題，再設計對應的領域模型，最后通過領域模型驅動代碼設計的實現。這樣設計的系統才有合理的分層與解耦，對以后業務的迭代開發，代碼的維護才更加容易。

然而很多互聯網公司，為了追求快速的上線，都是模型都沒有想清楚就開始寫代碼，這就導致了后續代碼維護困難，無法擴展。修改bug同時又引入新的bug，反反復復，進入惡性循環。

當然，這跟梳理清楚領域模型需要一定時間，這與初創型的互聯網公司需求快速上線有點相悖，但是，這點時間的投入是非常值得的。因為可以避免了系統上線后不久又得重構的問題。

概念總結

• 領域就是問題域
• 模型驅動的思想：通過建立領域模型來解決領域中的核心問題
• 領域建模的目標：針對我們在領域中核心問題，而不是整個領域中的所有問題
• 領域模型設計：設計時應考慮一定的抽象性、通用性，以及復用價值
• 代碼實現：通過領域模型驅動代碼的實現，確保代碼讓領域模型落地，代碼最終能解決問題

為什么需要DDD

系統復雜性

耦合

隨著產品不斷的迭代，業務邏輯變得越來越復雜，系統也越來越龐大。模塊彼此互相關聯、耦合。導致增加或修改一個功能變得異常艱難，同時功能間的界限也變得模糊，職責不再清晰。這個時候就需要進行重構，拆分。

雖然架構本身是隨著業務進行不斷演進的；但是，如果架構初始設計不體現出業務的模型，那么新需求就無法體現在現有架構上，導致不斷腐化，不斷重構。

內聚

貧血模型 Anemic Domain Object

domain object僅用作數據載體，而沒有行為和動作的領域對象。

指領域對象里只有get和set方法，沒有相關領域對象的業務邏輯。業務邏輯放在業務層。

充血模型 Rich Domain Object

將業務邏輯和對象存儲放在domain object里面，業務層只是簡單進行小部分業務的封裝及其他domain的編排。

面向對象設計，符合單一職責設計。

貧血 vs 充血

貧血模型的domain object很輕量，這導致業務層的復雜，domain object相關的業務邏輯散布在各個業務層，造成業務邏輯的冗余以及原本domain object的定義就變得相對模糊，這就是貧血癥引起的失憶癥。

而采用領域開發的方式，將數據和行為封裝在一起，與業務對象相映射；領域對象職責清晰，將相關業務聚合到領域對象內部。

微服務

DDD 的本質是一種軟件設計方法論，而微服務架構是具體的實現方式。微服務架構并沒有定義對復雜系統進行分解的具體方法論，而 DDD 正好就是解決方案。

微服務架構強調從業務維度來分治系統的復雜度，而DDD也是同樣的著重業務視角。

DDD能帶來什么

• 建立通用語言： 圍繞領域模型建立的一種語言，團隊所有成員都使用這種語言進行溝通和活動
• 驅動代碼設計：領域建立模型，模型指導設計，設計產出代碼
• 解決核心問題：模型的設計中心就是核心域，就是解決核心的問題

DDD建模

戰略設計

戰略設計就是從宏觀角度對領域進行建模。劃分出業務的邊界，組織架構，系統架構。

DDD中，對系統的劃分是基于領域的，也是基于業務的。

通用語言Ubiquitous Language

通用語言是指確定統一的領域術語，提高開發人員與領域專家之間的溝通效率。

一旦確定了統一語言，無論是與領域專家的討論，還是最終的實現代碼，都可以通過使用相同的術語，清晰準確地定義領域知識。

當確認整個團隊統一的語言后，就可以開始進行領域建模。

領域和子域

領域Domain

一個領域本質上可以理解為就是一個問題域。只要我們確定了系統所屬的領域，那這個系統的核心業務，即要解決的關鍵問題、問題的范圍邊界就基本確定了。

舉例

• 社交領域：關鍵問題是用戶推薦，聊天
• 電商領域：關鍵問題是購物，訂單，物流

子域Subdomain

如果一個領域過于復雜，涉及到的領域概念、業務規則、交互流程太多，導致沒辦法直接針對這個大的領域進行領域建模。這時就需要將領域進行拆分，本質上就是把大問題拆分為小問題，把一個大的領域劃分為了多個小的領域(子域)，那最關鍵的就是要理清每個子域的邊界

子域可以根據自身重要性和功能屬性劃分為三類子域：

• 核心域：公司核心產品和業務的領域
• 支撐子域：不包含決定產品和公司核心競爭力的功能，也不包含通用功能的子域
• 通用子域：被多個子域使用的通用功能子域

每個領域的劃分都不一樣。對相同領域公司而言，其核心，支撐，通用的子域也可能有不一樣的地方，但大體上基本都是一樣的。

舉例

社交領域的劃分

• 核心域：用戶推薦，聊天
• 支撐子域：客服，反垃圾
• 通用子域：消息推送

限界上下文Bounded Context

限界上下文

限界指劃分邊界，上下文對應一個聚合，限界上下文可以理解為業務的邊界。

一個子域對應一個或多個限界上下文。如果對應多個上下文，則可以考慮子域是否要再進行細粒度的拆分。

限界上下文的目的是為了更加明確領域模型的職責和范圍

劃分限界上下文

三個原則：

• 概念相同，含義不同(通用語言)：如果一個模型在一個上下文里面有歧義，那有歧義的地方就是邊界所在，應該把它們拆到不同的限界上下文中。
• 外部系統：有時候系統需要同外部系統交互，這時可以把與外部系統交互的那部分拆分出去以實現更好的擴展性。這樣一旦外部系統發生了變化，就不會影響到我們的核心業務邏輯。
• 組織擴展：盡量不要兩個團隊一起在一個限界上下文里面開發，因為這樣可能會存在溝通不順暢、集成困難等問題。

組織架構

康威定律

任何組織在設計一套系統時，所交付的設計方案在結構上都與該組織的溝通結構保持一致。

團隊結構就是組織結構，限界上下文就是系統的業務結構。所以，團隊結構應該盡量和限界上下文保持一致。

舉例

社交領域中，訂單子域對應訂單上下文

上下文映射

從宏觀上看每個上下文之間的關系，可以更好理解各個上下文之間的依賴關系。

梳理清楚上下文之間的關系是為了：

• 任務更好拆分，一個開發人員可以全身心的投入到相關的一個單獨的上下文中
• 溝通更加順暢，一個上下文可以明確自己對其他上下文的依賴關系，從而使得團隊內開發直接更好的對接
• 每個團隊在它的上下文中能夠更加明確自己領域內的概念，因為上下文是領域的解系統

舉例

聊天上下文依賴消息推送，推廣上下文也依賴消息推送

戰術建模

戰術建模是從微觀角度對上下文進行建模。

梳理清楚聚合根，實體，值對象，領域服務，領域事件，資源庫等。

實體Entity

當一個對象可以由標識進行區分時，這種對象稱為實體

和數據庫中的實體是不同的，這里的實體是從業務角度進行劃分的。

實體：

• 具有唯一標識
• 持久化
• 可變

舉例

社交中的用戶即為實體，可以通過用戶唯一的id進行區分。

值對象value object

當一個對象用于對事物進行描述而沒有唯一標識時，它被稱作值對象。

在實踐中，需要保證值對象創建后就不能被修改，即不允許外部再修改其屬性。

例如：年齡，聊天表情符號( :stuck_out_tongue:: 吐舌 (U+1F61B))

習慣了使用數據庫的數據建模后，很容易將所有對象看作實體

聚合根Aggregate Root

聚合是一組相關對象的集合，作為一個整體被外界訪問，聚合根是這個聚合的根節點。

聚合由根實體，值對象和實體組成。(聚合根里面有多少個實體，由領域建模決定)

外部對象需要訪問聚合內的實體時，只能通過聚合根進行訪問，而不能直接訪問

舉例

一個訂單是一個聚合根，訂單購買的商品是實體，收貨地址是值對象。

領域服務Domain Service

領域服務

一些既不是實體，也不是值對象的范疇的領域行為或操作，可以放到領域服務中。用來處理業務邏輯，協調領域對象來完成相關業務。

例如，有些業務邏輯不適合放到領域對象中，或實體之間的業務協調，這些業務邏輯都可以放到領域服務中。

特征

• 與領域相關的操作如執行一個業務操作過程，但它又并不適合放入實體與值對象中
• 操作是無狀態的
• 對領域對象進行轉換，或以多個領域對象作為輸入進行計算，結果產生一個值對象

當采用微服務架構風格，一切領域邏輯的對外暴露均需要通過領域服務來進行。

如原本由聚合根暴露的業務邏輯也需要依托于領域服務。

舉例

必須通過訂單領域服務來創建和訪問訂單

領域事件

領域事件是對領域內發生的活動進行的建模。捕獲一些有價值的領域活動事件。

作用

• 解耦：可以通過發布訂閱模式，發布領域事件
• 一致性：通過領域事件來達到最終一致性
• 事件溯源

舉例

發送聊天消息，這屬于一個領域事件；撤回消息，也屬于一個領域事件。

推送服務訂閱消息事件，然后將消息推送給用戶端。這樣就解耦了消息服務與推送服務之間的強依賴關系。

資源庫Repository

資源庫用于保存和獲取聚合對象。

領域模型 vs 數據模型

資源庫介于領域模型(業務模型)和數據模型(數據庫)之間，主要用于聚合對象的持久化和檢索。

資源庫隔離了領域模型和數據模型，以便上層只需要關注于領域模型而不需要考慮如何進行持久化。

分層架構

把一系列相同的對象進行分類放在同一層，然后根據他們之間的依賴關系再確定上下層次關系。

在實際決策時，我們需要知道各層的職責、意義以及相應的場景；

落實到代碼層面時，我們還需要知道各層所包含的具體內容、各層的一些常見的具體策略/模式、層次之間的交互/依賴關系。

DDD經典分層架構

• 用戶接口層(interfaces)：處理顯示和用戶請求，以及一些基本的參數檢查，不包括業務邏輯
• 應用層(application)：主要協調領域對象的操作；處理持久化事務、發送消息、安全認證等
• 領域層(domain)：處理核心業務邏輯，不包括技術實現細節。領域層是業務軟件的核心
• 基礎設施層(infrastructure)：處理純技術細節，為其他層提供技術支撐，也可用于封裝調用的外部系統細節。例如：持久化的實現，消息中間件的實現，工具類，rpc等

個人理解：這種分層，既可以在一個單體應用中，也可以是微服務的形式。DDD分層并不一定要按微服務的服務粒度進行分層。

如果一個業務邏輯非常簡單的子域，則可以將幾層都放進一個單體應用中，在應用中進行分層。如果業務較為復雜，則可以按服務進行拆分，每層都有自己對應的服務。

其他架構

• 對稱性架構
• 洋蔥架構
• 整潔架構
• CQRS架構

DDD工程實踐

以一個簡化的社交領域的例子來實踐DDD。

核心概念

• 用戶(User)： 一個賬戶，并以用戶id識別
• 關系(Relationship)：用戶之間的關系
• 動態(Feed)： 用戶發布文字，圖片，視頻，評論等內容
• 會話(Conversation)：用戶之間的聊天會話

領域設計

戰略建模

領域就是社交領域，核心問題和絕大部分社交系統一樣。

子域

• 核心域：聊天，動態
• 支撐子域：反作弊，推廣
• 通用子域：用戶，關系，消息推送

上下文

• 消息上下文
• 會話上下文
• 動態上下文
• 推送上下文
• 用戶上下文

戰術建模

以會話上下文為例子來進行戰術建模

會話上下文

• 會話：聚合根用戶：實體用戶：實體消息列表：實體發送人：實體接收人：實體消息內容：值對象

消息在會話上下文屬于實體，在消息上下文屬于聚合根。

結構

以會話子域為例

架構分層

• interfaces 接口層RESTfulRPC
• application 應用層ConversationMessage
• domain_service 領域服務層modelConversationMessagerepositoryConversationMessage
• infrastructure 基礎設施層storeConversationRepositoryMessageRepositorymessageSendMessageutils

領域

package domain// 聚合根type Conversation struct { ID int User1 User User2 User Messages list.List}// 實體type Message struct { ID int From User // 實體 To User Body Content // 值對象}

用戶接口層

type ChatInferface struct { // 應用層 app app.ChatApplication}func (c *ChatInferface) Route() { c.route("POST", "/api/message", c.SendMessage) c.route("PATCH", "/api/message", c.RecallMessage)}// POST /api/messagefunc (c *ChatInferface) SendMessage(ctx *Context) { if !c.validateRequest(ctx) { return } message := c.parseMessage(ctx) app.SendMessage(message)}func (c *ChatInferface) RecallMessage(ctx *Context) { if !c.validateRequest(ctx) { return } messageID := c.parseMessage(ctx) app.RecallMessage(messageID)}

應用層

type ChatApplication struct { user service.UserService chat service.ChatService // 這里領域事件由應用層發布 // publisher EventPublisher lbs LBSFacade}func (c *ChatApplication) SendMessage(msg *Message) { if !c.user.CheckUser(msg.UserID) { return } c.chat.SendMessage(msg)}

領域服務層

type ChatService struct { // 領域事件 publisher MessageEventPublisher repo MessageRepository}func (c *ChatService SendMessage(msg *Message) { // 業務邏輯 ... // 領域資源持久化 c.repo.Save(msg) // 發布領域事件 c.publisher.Publish(msg)}

基礎設施層

package infrastructuretype MessageRepository struct { db MessageDatabase cache MessageCache}func (m *MessageRepository) Save(msg *Message) { db.Save(m.ToPO(msg))}func (m MessageRepository) Get(msgID int) *Message { msg := m.cache.Get(msgID) if msg != nil { return m.FromPO(msg) } return m.FromPO(m.db.Get(msgID))}

總結

在設計和實現一個系統的時候，這個系統所要處理問題的領域專家和開發人員以一套統一語言進行協作，共同完成該領域模型的構建，在這個過程中，業務架構和系統架構等問題都得到了解決，之后將領域模型中關于系統架構的主體映射為實現代碼，完成系統的實現落地。

總結

以上是生活随笔為你收集整理的nvme通用驱动_对领域驱动设计的理解与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。