概述

DDD（Domain-Driven Design 領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)）是由Eric Evans最先提出，目的是對(duì)軟件所涉及到的領(lǐng)域進(jìn)行建模，以應(yīng)對(duì)系統(tǒng)規(guī)模過(guò)大時(shí)引起的軟件復(fù)雜性的問(wèn)題。整個(gè)過(guò)程大概是這樣的，開發(fā)團(tuán)隊(duì)和領(lǐng)域?qū)＜乙黄鹜ㄟ^(guò) 通用語(yǔ)言(Ubiquitous Language)去理解和消化領(lǐng)域知識(shí)，從領(lǐng)域知識(shí)中提取和劃分為一個(gè)一個(gè)的子領(lǐng)域（核心子域，通用子域，支撐子域），并在子領(lǐng)域上建立模型，再重復(fù)以上步驟，這樣周而復(fù)始，構(gòu)建出一套符合當(dāng)前領(lǐng)域的模型。

DDD概述

這里需要注意幾點(diǎn)：

• 通用語(yǔ)言是一個(gè)很泛的概念，它作為一種溝通工具，在開發(fā)團(tuán)隊(duì)內(nèi)部，開發(fā)團(tuán)隊(duì)與領(lǐng)域?qū)＜抑g使用。它包含了自然語(yǔ)言、文檔和圖表（不一定是標(biāo)準(zhǔn)的UML圖，只要能表達(dá)出領(lǐng)域知識(shí)的都可以）等內(nèi)容。對(duì)通用語(yǔ)言中名詞，動(dòng)詞的使用需要認(rèn)真考量，因?yàn)檫@些名詞和動(dòng)詞會(huì)作為后面模型的指導(dǎo)命名。
• 通用語(yǔ)言中定義的術(shù)語(yǔ)在一個(gè) 限界上下文(bounded context)中不能存在二義性。同一個(gè)事物在不同的限界上下文中因?yàn)樗P(guān)注的側(cè)重點(diǎn)不同，所以所表達(dá)出的概念是不同的，但在同一個(gè)限界上下文中應(yīng)該表示的是一個(gè)概念。比如用戶在微信中的聊天場(chǎng)景，朋友圈以及支付場(chǎng)景中所有表達(dá)的概念就應(yīng)該是不同的，聊天場(chǎng)景關(guān)注的是用戶間的聊天內(nèi)容，而支付場(chǎng)景關(guān)注的是用戶的賬戶余額。
• 一個(gè)子域可以包含多個(gè)限界上下文。
• 模型（Entity，值對(duì)象，Service，Aggregate root）是存在于限界上下文中的。

分層架構(gòu)

DDD中將系統(tǒng)分為UI層，應(yīng)用層，領(lǐng)域?qū)右约盎A(chǔ)設(shè)施層。

分層架構(gòu)

上圖中，應(yīng)用層是很薄的一層，因?yàn)樗回?fù)責(zé)接收UI層傳來(lái)的參數(shù)和路由到對(duì)應(yīng)的領(lǐng)域模型，它不負(fù)責(zé)處理具體的業(yè)務(wù)邏輯。系統(tǒng)的業(yè)務(wù)邏輯放在了領(lǐng)域?qū)又?#xff0c;所以，領(lǐng)域?qū)釉谙到y(tǒng)架構(gòu)中占據(jù)了很大的面積。

在層級(jí)結(jié)構(gòu)中，上層模塊調(diào)用下層模塊提供的服務(wù)，這里就會(huì)存在一種依賴關(guān)系，Rebort C. Martin提出的依賴倒置原則大致是如下：

上層模塊不應(yīng)該依賴于下層模塊，兩者都應(yīng)該依賴于抽象；
抽象不應(yīng)該依賴于實(shí)現(xiàn)，實(shí)現(xiàn)應(yīng)該依賴于抽象;

這是一個(gè)面向接口編程的思想，抽象說(shuō)的是抽象類或接口，實(shí)現(xiàn)就是具體實(shí)現(xiàn)了這些抽象的實(shí)現(xiàn)類。翻譯成白話文是這樣的，上下層之間應(yīng)該通過(guò)接口來(lái)通訊，接口定義的位置就決定了上下層的依賴關(guān)系是否倒置。比如Application層和Domain層進(jìn)行通訊，接口與接口的實(shí)現(xiàn)類都定義在Domain層中，這是正常的面向接口編程，不存在倒置關(guān)系。而Domain層和基礎(chǔ)設(shè)施層進(jìn)行通訊時(shí)，原本是Domain層去依賴基礎(chǔ)設(shè)施層，如果我們將接口定義在Domain層，而實(shí)現(xiàn)類定義在基礎(chǔ)設(shè)施層，那么，基礎(chǔ)設(shè)施層就將依賴Domain層，這就是“倒置”這個(gè)詞的來(lái)由。實(shí)際上，我們?cè)谧鲞@樣分層架構(gòu)設(shè)計(jì)時(shí)，都是將接口定義在Domain層的。

DDD元素

在使用DDD設(shè)計(jì)系統(tǒng)時(shí)，主要包括Entity，Value Object，Service,Aggregate,Repository,Factory,Domain Event,Moudle等元素。

ddd元素

在建模時(shí)，Entity可以用來(lái)代表一個(gè)事物。既然Entity是用來(lái)代表一個(gè)事物的，那么它就應(yīng)該有一個(gè)唯一值來(lái)標(biāo)識(shí)這個(gè)事物，同時(shí)，他還能記錄這個(gè)事物狀態(tài)的變化。比如：Id為5的Person對(duì)象，它的名字是張三，過(guò)兩天，他將自己的名字改為李四。但是，這個(gè)人（Id=5）還是這個(gè)人（Id=5），只是他名字的狀態(tài)以及發(fā)生了變化，而這個(gè)變化后的狀態(tài)被Person這個(gè)Entity記錄了下來(lái)。

Value Object是用來(lái)描述事物的某一方面的特征，所以它是一個(gè)無(wú)狀態(tài)的，且是一個(gè)沒有標(biāo)識(shí)符的對(duì)象，這是和Entity的本質(zhì)區(qū)別。拿訂單來(lái)說(shuō)，一張訂單在系統(tǒng)中應(yīng)該有一個(gè)唯一的標(biāo)識(shí)，且具有狀態(tài)，所以訂單是一個(gè)Entity對(duì)象，而這張訂單共￥100元，則是描述了這個(gè)訂單的總額特征，￥100元可以用值對(duì)象表示為{100，￥}，及金額和幣種的組合。{100，￥}在任何限界上下文中都描述的是￥100元，是因?yàn)樗麄儽容^的是里面的內(nèi)容（金額和幣種），而上面的張三在修了名后，還是原來(lái)的那個(gè)人，是因?yàn)樗容^的是唯一標(biāo)示ID的值。

Aggregate是一組相關(guān)對(duì)象的集合，它作為數(shù)據(jù)修改的基本單元，為數(shù)據(jù)修改提供了一個(gè)邊界。每個(gè)聚合都有一個(gè)根和一個(gè)邊界，根也是一個(gè)實(shí)體，聚合邊界以外的對(duì)象只能通過(guò)根對(duì)聚合內(nèi)部元素操作。聚合將一組相關(guān)的對(duì)象內(nèi)聚到一起，從而將系統(tǒng)的復(fù)雜程度降低。

repository用來(lái)存儲(chǔ)聚合，相當(dāng)于每一個(gè)聚合都應(yīng)該有一個(gè)倉(cāng)庫(kù)實(shí)例。Entity和Value Object都應(yīng)該具有行為，而有些行為從語(yǔ)義上講，不適合放到這兩個(gè)對(duì)象中，所以就單獨(dú)抽象了一個(gè)Service對(duì)象，用來(lái)存放這些行為。Factory是用來(lái)生成聚合的，當(dāng)生成一個(gè)聚合的步驟過(guò)于復(fù)雜時(shí)，可以將其生成過(guò)程放在工廠中。

作者：書上得來(lái)終覺淺
鏈接：https://www.jianshu.com/p/b0379067c978
來(lái)源：簡(jiǎn)書
簡(jiǎn)書著作權(quán)歸作者所有，任何形式的轉(zhuǎn)載都請(qǐng)聯(lián)系作者獲得授權(quán)并注明出處。

總結(jié)

以上是生活随笔為你收集整理的DDD 领域驱动设计 教程的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。