企業(yè)應(yīng)用架構(gòu)模式中明確提出了三種領(lǐng)域邏輯組織模式：事務(wù)腳本、領(lǐng)域模型和表模塊。不少人看的云里霧里的，不少人說的似懂非懂的，主要原因是沒有從項(xiàng)目的級(jí)別的分析和設(shè)計(jì)經(jīng)驗(yàn)，只有單個(gè)項(xiàng)目模塊的開發(fā)經(jīng)驗(yàn)的人很難理解到位。

?

1.事務(wù)腳本：

事務(wù)腳本的理解其實(shí)最簡(jiǎn)單，但是很多人說不清，覺得比領(lǐng)域模型還難理解，也對(duì)應(yīng)不到代碼。但這只是幻覺，怎么可能最簡(jiǎn)單的領(lǐng)域邏輯模式都不懂，反而對(duì)最復(fù)雜的領(lǐng)域模型模式懂了呢。

我們看企業(yè)應(yīng)用架構(gòu)模式中強(qiáng)調(diào)的一句話"使用過程來組織領(lǐng)域邏輯"，其實(shí)事務(wù)腳本就是從過程的角度看待需求，需求方和開發(fā)方在此階段都熱衷的核心是"這個(gè)功能是怎么個(gè)過程"，二者達(dá)成一致后用代碼去將這個(gè)粗糙的過程模擬出來。所以大多數(shù)人都在不自覺的應(yīng)用事務(wù)腳本模式。簡(jiǎn)單說就是使用過程化的代碼在模擬用戶表面的需求。如果這個(gè)項(xiàng)目繼續(xù)進(jìn)行下去，那么問題來了：

（1）用戶自己都不太清楚需求，需求肯定會(huì)隨著用戶的想法變化而不斷變化。即使你作為需求方如果不仔細(xì)思考，只是簡(jiǎn)單的陳述下表面的流程，你也會(huì)經(jīng)常性的由于自己偶爾的深入考慮或更沒譜的想法而不斷的變更需求。

（2）事務(wù)腳本模式的代碼是過程式的，需要什么調(diào)用什么，常見的數(shù)據(jù)源通信、郵件服務(wù)、應(yīng)用級(jí)別的日志安全等各種代碼都混合在一起，如果需求變了，調(diào)整起來很困難。

?

這就是很多項(xiàng)目的一般狀態(tài)，因?yàn)閱栴}的根源在沒有深入分析和理解用戶的需求，所以不是用什么框架和分層，搞一些似是而非的實(shí)體或者采用了IOC和AOP等技術(shù)實(shí)現(xiàn)能起作用的的。還是要從根源上尋求解決之道，因此領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)強(qiáng)調(diào)通用語言，這樣才能同需求人員一起對(duì)具體的領(lǐng)域進(jìn)行深入的分析，這樣的需求分析和模型設(shè)計(jì)具有更高的穩(wěn)定性，才不會(huì)因?yàn)樾枨蠓降哪X抽和風(fēng)暴導(dǎo)致需求頻發(fā)大幅度變化。

?

一旦你了解了事務(wù)腳本模式的核心，你就十分清楚事務(wù)腳本的適用范圍：

（1）領(lǐng)域邏輯本身就是多個(gè)簡(jiǎn)單過程。

（2）需求十分簡(jiǎn)單，即使看起來表面化也已經(jīng)足夠深入。

?

在此提醒大家，要學(xué)習(xí)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)千萬別跑偏，不要忘記領(lǐng)域邏輯本身才是一切的分析和設(shè)計(jì)的根源。尤其是初學(xué)者千萬不要把非領(lǐng)域?qū)雍蛻?yīng)用層的各種框架技術(shù)和組件之類的混入到學(xué)習(xí)中。在分析和設(shè)計(jì)的過程中，至少要堅(jiān)持兩點(diǎn)：

（1）不要在此時(shí)關(guān)注表示層和數(shù)據(jù)源層

（2）盡量多從項(xiàng)目整體的角度看待問題，不要只以開發(fā)者的角度去思考。

?

事務(wù)腳本依然可以使用各種技術(shù)和框架，但無論你怎么命名文件和使用什么組件，依然是以過程來組織業(yè)務(wù)邏輯。以事務(wù)腳本模式組織領(lǐng)域邏輯的設(shè)計(jì)結(jié)果必然是以一系列的流程圖為核心。

?

2.表模塊：

表模塊不再將過程作為組織領(lǐng)域邏輯的核心，而是將數(shù)據(jù)作為領(lǐng)域邏輯的核心。一些在深受事務(wù)腳本模式的毒害的團(tuán)隊(duì)可能意識(shí)到了過程的變化太不可預(yù)測(cè)了，而往往又不去或不能在需求分析上下功夫，因此從技術(shù)角度抓住了業(yè)務(wù)邏輯中相對(duì)過程更穩(wěn)定的數(shù)據(jù)部分。也僅此而已。采用表模塊的模式往往有以下兩個(gè)結(jié)果：

（1）設(shè)計(jì)的結(jié)果主要是E-R圖或披著類圖皮的E-R圖。

（2）自然的采用數(shù)據(jù)模型但堅(jiān)持認(rèn)為是領(lǐng)域模型。

?

也自然而然的得到表模塊的適用范圍：

（1）業(yè)務(wù)邏輯本身就是以數(shù)據(jù)為核心的簡(jiǎn)單處理。

（2）業(yè)務(wù)邏輯的流程十分簡(jiǎn)單，這點(diǎn)和事務(wù)腳本是一致的。

?

3.領(lǐng)域模型：

領(lǐng)域模型同時(shí)將行為和數(shù)據(jù)作為領(lǐng)域邏輯的核心。因此無法像事務(wù)腳本一樣只關(guān)心過程和表面需求，也無法像表模塊一樣只關(guān)心數(shù)據(jù)。問題終于清晰了：

（1）事務(wù)腳本模式不（或逃避）深入分析需求。

（2）表模塊強(qiáng)調(diào)了數(shù)據(jù)，得不到充分的領(lǐng)域模型。

（3）領(lǐng)域模型模式采用通用語言解決需求問題，采用過程和數(shù)據(jù)結(jié)合解決領(lǐng)域邏輯的組織。

?

實(shí)在是不能說的再復(fù)雜了，因?yàn)楸举|(zhì)上的簡(jiǎn)單。由于領(lǐng)域邏輯本身的特性，往往會(huì)產(chǎn)生以下兩種傾向的領(lǐng)域模型：

（1）形式上類似事務(wù)腳本模式的領(lǐng)域模型，這是由于領(lǐng)域邏輯本身的特性決定，即使從代碼上看起來十分相似，但是具有更穩(wěn)定和更少需求變動(dòng)的優(yōu)勢(shì)。

（2）形式上類似表模塊模式的領(lǐng)域模型。其他同上。

?

優(yōu)勢(shì)也是實(shí)在太明顯了。我實(shí)在不能拒絕。這不是技術(shù)上的問題，這是需求分析和模型設(shè)計(jì)上的問題，我實(shí)在不能把這些簡(jiǎn)單的概念搞的更復(fù)雜了。在使用和不斷完善通用語言的需求分析過程中，通過多次深入分析和迭代我們得到了比較穩(wěn)定的需求分析，在完善設(shè)計(jì)的過程中，我們通過使用和識(shí)別出實(shí)體、值對(duì)象、領(lǐng)域服務(wù)和領(lǐng)域事件等概念，劃分出聚合、子域、界限上下文來簡(jiǎn)化我們的設(shè)計(jì)。這是在以領(lǐng)域邏輯為核心的前提下，不斷深入、細(xì)化和迭代的自然結(jié)果。

?

再次強(qiáng)調(diào)：

（1）DDD屬于設(shè)計(jì)范疇而非實(shí)現(xiàn)范疇。

（2）DDD屬于領(lǐng)域?qū)拥脑O(shè)計(jì)，別扯到架構(gòu)和框架上。

（3）DDD的核心是通用語言和模型驅(qū)動(dòng)設(shè)計(jì)。

轉(zhuǎn)載于:https://www.cnblogs.com/easygame/p/4461142.html

總結(jié)

以上是生活随笔為你收集整理的领域驱动系列：三种领域逻辑组织模式的本质的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

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