本篇內(nèi)容主要講解“如何理解領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)概念”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“如何理解領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)概念”吧!

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

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

借用美團(tuán)的文章：

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

1. 基本概念

DDD是對(duì)面向?qū)ο笤O(shè)計(jì)的改進(jìn)，是開發(fā)復(fù)雜業(yè)務(wù)邏輯的一種方法。有利于指導(dǎo)應(yīng)用程序分解為服務(wù)，每個(gè)微服務(wù)都有自己的領(lǐng)域。要靈活應(yīng)用DDD來進(jìn)行設(shè)計(jì)就需要知道他所提出的名詞及概念。

1. 1 領(lǐng)域domain、子域和限界上下文

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

子域：領(lǐng)域下拆分的部分

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

1.2 領(lǐng)域服務(wù)domain service、應(yīng)用層

應(yīng)用層：對(duì)應(yīng)開發(fā)中的controller或API接口。

領(lǐng)域服務(wù)：處理領(lǐng)域的業(yè)務(wù)邏輯，實(shí)現(xiàn)不屬于實(shí)體或值對(duì)象的業(yè)務(wù)邏輯對(duì)象

1.3 聚合aggregate、聚合根 aggregate root、實(shí)體entity、值對(duì)象value object

聚合：領(lǐng)域中有多個(gè)聚合，是一個(gè)邊界內(nèi)的領(lǐng)域?qū)ο蟮募海筛鶎?shí)體和可能一個(gè)或多個(gè)其他實(shí)體和值對(duì)象組成，引用聚合必須通過表示

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

實(shí)體：內(nèi)部擁有唯一ID，具有相同屬性的兩個(gè)實(shí)體仍然是不同的對(duì)象

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

1.5 倉庫repository

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

1.6 基礎(chǔ)設(shè)施infrastructure

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

1.7 工廠 factory

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

2. 核心思想

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的核心思想明顯就是對(duì)于領(lǐng)域的劃分。領(lǐng)域中的事務(wù)也需要考慮

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

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

有贊對(duì)包模塊是這樣劃分的

結(jié)合對(duì)項(xiàng)目淺顯理解，改造包結(jié)構(gòu)為：

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

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

4. CQRS

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

• command bus：將多個(gè)command 分發(fā)至對(duì)應(yīng)的command handle中進(jìn)行處理

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

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

• command handle：處理command

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

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

實(shí)現(xiàn)簡單的CQRS

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

5. 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)并不是銀彈

目前市面主流方法論有

• OOA/OOD/OOP 面向?qū)ο蟮姆治鲈O(shè)計(jì)與方法，通常用UML進(jìn)行建模描述

• ER建模，即數(shù)據(jù)驅(qū)動(dòng)開發(fā)，根據(jù)業(yè)務(wù)設(shè)計(jì)數(shù)據(jù)庫表結(jié)構(gòu)進(jìn)行開發(fā)

• DDD 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)

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

6. 總結(jié)

領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的優(yōu)缺點(diǎn)都非常明顯。

缺點(diǎn)

• 學(xué)習(xí)成本、團(tuán)隊(duì)意識(shí)要求，需要對(duì)業(yè)務(wù)高度抽象

• 需要領(lǐng)域?qū)＜遗c技術(shù)人員拉通統(tǒng)一領(lǐng)域語言，耗時(shí)大，與現(xiàn)在流行的Scrum敏捷開發(fā)相背離

• 業(yè)務(wù)變化的復(fù)雜性，需要識(shí)別多變業(yè)務(wù)進(jìn)行領(lǐng)域建模，出現(xiàn)“缺乏設(shè)計(jì)”與“過度設(shè)計(jì)”

優(yōu)點(diǎn)

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

• 復(fù)雜業(yè)務(wù)分治

如何使用

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

2. 劃分領(lǐng)域、限界上線文等基礎(chǔ)部件

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

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

當(dāng)前標(biāo)題：如何理解領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)概念
文章源于：http://aaarwkj.com/article18/iipegp.html

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

廣告

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