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

保山網(wǎng)站建設公司成都創(chuàng)新互聯(lián)公司,保山網(wǎng)站設計制作，有大型網(wǎng)站制作公司豐富經(jīng)驗。已為保山1000+提供企業(yè)網(wǎng)站建設服務。企業(yè)網(wǎng)站搭建\成都外貿網(wǎng)站制作要多少錢，請找那個售后服務好的保山做網(wǎng)站的公司定做！

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

借用美團的文章：

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

1. 基本概念

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

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

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

子域：領域下拆分的部分

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

1.2 領域服務domain service、應用層

應用層：對應開發(fā)中的controller或API接口。

領域服務：處理領域的業(yè)務邏輯，實現(xiàn)不屬于實體或值對象的業(yè)務邏輯對象

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

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

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

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

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

1.5 倉庫repository

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

1.6 基礎設施infrastructure

常用的工具類，底層數(shù)據(jù)庫持久化

1.7 工廠 factory

將聚合根生成的復雜過程放入工廠類中實現(xiàn)

2. 核心思想

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

3. Java落地實現(xiàn)

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

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

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

• infrastructure：里面放入了現(xiàn)有對dao層和util

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

4. CQRS

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

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

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

• event bus：事件總線，異步將event寫入數(shù)據(jù)庫

• command handle：處理command

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

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

實現(xiàn)簡單的CQRS

現(xiàn)有Axon框架按照DDD思想設計等CQRS框架。

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

目前市面主流方法論有

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

• ER建模，即數(shù)據(jù)驅動開發(fā)，根據(jù)業(yè)務設計數(shù)據(jù)庫表結構進行開發(fā)

• DDD 領域驅動設計

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

6. 總結

領域驅動設計的優(yōu)缺點都非常明顯。

缺點

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

• 需要領域專家與技術人員拉通統(tǒng)一領域語言，耗時大，與現(xiàn)在流行的Scrum敏捷開發(fā)相背離

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

優(yōu)點

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

• 復雜業(yè)務分治

如何使用

1. 首先判斷業(yè)務是否足夠復雜多變，相對穩(wěn)定建模

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

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

到此，相信大家對“如何理解領域驅動設計概念”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！

當前標題：如何理解領域驅動設計概念
文章源于：http://vcdvsql.cn/article18/iipegp.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站導航、自適應網(wǎng)站、小程序開發(fā)、標簽優(yōu)化、手機網(wǎng)站建設、商城網(wǎng)站

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)