軟件系統(tǒng)是通過軟件開發(fā)來解決某一個(gè)業(yè)務(wù)領(lǐng)域或問題單元而產(chǎn)生的一個(gè)交付物。而通過軟件設(shè)計(jì)可以幫助我們開發(fā)出更加健壯的軟件系統(tǒng)。因此，軟件設(shè)計(jì)是從業(yè)務(wù)領(lǐng)域到軟件開發(fā)之間的橋梁。而DDD是軟件設(shè)計(jì)中的其中一種思想，旨在提供一種大型復(fù)雜軟件的設(shè)計(jì)思路和規(guī)范。通過DDD思想可以讓我們的業(yè)務(wù)架構(gòu)、系統(tǒng)架構(gòu)、部署架構(gòu)、數(shù)據(jù)架構(gòu)、工程架構(gòu)等都具備高擴(kuò)展性、高維護(hù)性和高測(cè)試性。

但是落地DDD是一件很困難的事情。首先在思想認(rèn)知層面就比較難以突破。

DDD本身是一種思想，不是某種具體的技術(shù)，因此在代碼實(shí)現(xiàn)和系統(tǒng)架構(gòu)層面沒有約束。而由于市面上成熟的ORM框架(比如hibernate、mybatis等)，使得大部分軟件開發(fā)都是直接面向數(shù)據(jù)庫開發(fā)。在傳統(tǒng)開發(fā)中的應(yīng)用分層架構(gòu)又和DDD思想的分層架構(gòu)很類似。從而導(dǎo)致很多人在初學(xué)DDD時(shí)有一定的理解偏差，從而導(dǎo)致無法落地DDD思想。

這篇文章記錄我對(duì)DDD的學(xué)習(xí)、感悟與項(xiàng)目工程代碼重構(gòu)實(shí)戰(zhàn)心得！

一、Domin Primitive

領(lǐng)域“元數(shù)據(jù)”的意思。主要是講解領(lǐng)域的基本準(zhǔn)則。這也是使用DDD思想的基本準(zhǔn)則。

1.1 隱性的概念顯性化

exp：電話號(hào)碼通常是由區(qū)號(hào)編碼+號(hào)碼組成。在實(shí)際的業(yè)務(wù)中會(huì)有很多需要電話號(hào)碼的業(yè)務(wù)。比如登錄認(rèn)證、導(dǎo)購分銷等業(yè)務(wù)；我們需要對(duì)電話號(hào)碼進(jìn)行基礎(chǔ)性校驗(yàn)；獲取區(qū)號(hào)編碼等；在常規(guī)操作下，會(huì)在每一個(gè)用到電話號(hào)碼的方法入口都會(huì)寫大量的這種校驗(yàn)代碼和判斷代碼，盡管我們可以將它的校驗(yàn)和獲取區(qū)號(hào)編碼抽離成util類（實(shí)際上大多數(shù)工程中都是這么做的），但這種方式治標(biāo)不治本。基于DDD思想可以發(fā)現(xiàn)這里有一個(gè)隱性概念：區(qū)號(hào)編碼。

我們可以基于DDD思想，將電話號(hào)碼創(chuàng)建為一個(gè)擁有獨(dú)立概念和行為的值對(duì)象：PhoneNumber，將基礎(chǔ)性校驗(yàn)和獲取編碼等無狀態(tài)行為封裝在值對(duì)象中。這樣在方法中就不需要再充斥著寫大量的校驗(yàn)和判斷。

1.2 隱性的上下文顯性化

exp：在銀行轉(zhuǎn)賬場(chǎng)景中，通常我們會(huì)說A賬戶給B賬戶轉(zhuǎn)1000元。這里的1000元實(shí)際上有兩層含義，數(shù)字1000，貨幣元。但我們通常會(huì)忽略貨幣單位元。導(dǎo)致在實(shí)現(xiàn)轉(zhuǎn)賬功能時(shí)，沒有考慮到單位。一旦有國際轉(zhuǎn)賬時(shí)，就又會(huì)陷入到大量的if else中。

我們基于DDD思想，將錢創(chuàng)建為一個(gè)擁有獨(dú)立概念和行為的值對(duì)象：Money，這樣我們所說的錢才具備完整的概念。通過這種方式就可以將貨幣這個(gè)隱性上下文顯性化，從而避免當(dāng)前未識(shí)別到但是未來可能會(huì)爆雷的bug。

1.3 封裝多對(duì)象行為

exp：在跨境轉(zhuǎn)賬的場(chǎng)景中，需要轉(zhuǎn)換匯率，我們可以將轉(zhuǎn)換匯率封裝成一個(gè)值對(duì)象。通過封裝金額計(jì)算邏輯和各種校驗(yàn)邏輯，使得整個(gè)方法極其簡(jiǎn)單。

1.4 DP和值對(duì)象的區(qū)別

DP是阿里大神提出來的概念；值對(duì)象是DDD思想中的概念。

學(xué)習(xí)之后，我個(gè)人認(rèn)為DP是對(duì)值對(duì)象的進(jìn)一步補(bǔ)充，使其擁有了更加完整的概念。在值對(duì)象【不變性】的基礎(chǔ)上補(bǔ)充了【可校驗(yàn)性】和【獨(dú)立行為】。當(dāng)然也是要求【無副作用】。所謂的無副作用就是【狀態(tài)不可變】。

1.5 DP和DTO的區(qū)別

1.6 使用DP VS 不使用DP

二、應(yīng)用架構(gòu)

2.1 DDD思想下的標(biāo)準(zhǔn)應(yīng)用架構(gòu)

傳統(tǒng)的MVC架構(gòu)分為展現(xiàn)層、業(yè)務(wù)邏輯層和數(shù)據(jù)訪問層，更加注重從展現(xiàn)層到數(shù)據(jù)訪問層自上而下的交互，編寫出來的代碼像是腳本式代碼。

而基于DDD原則，工程架構(gòu)被分為應(yīng)用層、領(lǐng)域?qū)雍突A(chǔ)設(shè)施層。將工程中不同的功能和職責(zé)劃分到不同的層級(jí)中。核心的業(yè)務(wù)邏輯放在領(lǐng)域?qū)又小?/p>

2.1.1 應(yīng)用層

按照DDD的思想，應(yīng)用層負(fù)責(zé)協(xié)調(diào)用戶界面和領(lǐng)域?qū)又g的交互?？梢酝ㄋ椎恼J(rèn)為是對(duì)領(lǐng)域服務(wù)的編排，其本身不包含任何業(yè)務(wù)邏輯。

2.1.2 領(lǐng)域?qū)?/p>

領(lǐng)域?qū)迂?fù)責(zé)實(shí)現(xiàn)核心業(yè)務(wù)的邏輯和規(guī)則。按照DDD的思想，這一層包含實(shí)體模塊、值對(duì)象模塊、事件、領(lǐng)域服務(wù)。

2.1.3 基礎(chǔ)設(shè)施層

基礎(chǔ)設(shè)施層不處理任何業(yè)務(wù)邏輯，只包含基礎(chǔ)設(shè)施，通常包含數(shù)據(jù)庫、定時(shí)任務(wù)、MQ、南向網(wǎng)關(guān)、北向網(wǎng)關(guān)等。

2.2 我對(duì)演進(jìn)出六邊形架構(gòu)的理解

2.2.1 再談應(yīng)用層

在實(shí)際業(yè)務(wù)邏輯當(dāng)中，除了用戶界面層之外，還有其他外部系統(tǒng)會(huì)調(diào)用本服務(wù)，比如xxljob、MQ、或者提供給外部系統(tǒng)調(diào)用http或者rpc接口等。因此在實(shí)際當(dāng)中，應(yīng)用層應(yīng)當(dāng)是協(xié)調(diào)外部系統(tǒng)與領(lǐng)域?qū)又g的交互。

按照標(biāo)準(zhǔn)架構(gòu)層級(jí)依賴關(guān)系來看，應(yīng)用層依賴了領(lǐng)域?qū)雍突A(chǔ)設(shè)施層。由于依賴了基礎(chǔ)設(shè)施層，因此破壞了應(yīng)用層本身的可維護(hù)性和測(cè)試性。因此我們需要基于接口進(jìn)行依賴倒置。

為了防止領(lǐng)域概念外泄，需要對(duì)應(yīng)用層進(jìn)一步的抽象為外部服務(wù)和內(nèi)部服務(wù)，所有外部服務(wù)必須通過內(nèi)部服務(wù)調(diào)用領(lǐng)域?qū)?。這樣就可以防止領(lǐng)域模型的外泄。

2.2.2 再談?lì)I(lǐng)域?qū)?/p>

同樣的，按照標(biāo)準(zhǔn)架構(gòu)層級(jí)依賴關(guān)系，領(lǐng)域?qū)右蕾嚮A(chǔ)設(shè)施層，但這也破壞了領(lǐng)域?qū)颖旧淼目删S護(hù)性和可測(cè)試性。因此我們基于DDD中的資源庫思想，抽象repository層，通過接口實(shí)現(xiàn)依賴反轉(zhuǎn)。讓領(lǐng)域?qū)硬辉僖蕾嚮A(chǔ)設(shè)施層。從而提高領(lǐng)域?qū)颖旧淼目删S護(hù)性和可測(cè)試性。

2.2.3 再談基礎(chǔ)設(shè)施層

對(duì)于基礎(chǔ)設(shè)施層而言，它主要作用是提供基礎(chǔ)設(shè)施的能力，比如數(shù)據(jù)庫、MQ、遠(yuǎn)程服務(wù)調(diào)用等。進(jìn)一步抽象可以發(fā)現(xiàn)它們就是端口和適配器。通過端口實(shí)現(xiàn)與外部系統(tǒng)的交互，通過適配器完成數(shù)據(jù)和概念的轉(zhuǎn)換。

2.2.4 演進(jìn)出六邊形架構(gòu)

通過依賴反轉(zhuǎn)，神奇的事情發(fā)生了?；A(chǔ)設(shè)施層變成了最外層。

我們結(jié)合對(duì)應(yīng)用層、領(lǐng)域?qū)雍突A(chǔ)設(shè)施層進(jìn)一步的理解再加上反轉(zhuǎn)后的應(yīng)用架構(gòu)，便可以得到六邊形架構(gòu)：

2.3 工具類、配置類的代碼應(yīng)該放在哪里？

在一個(gè)實(shí)際的工程當(dāng)中，除了上面所說的三層之外，通常會(huì)使用到一些工具類（JSON解析工具類、字符串工具類等）。各層可能都會(huì)使用到工具類。

從工具類的定位來看，它應(yīng)當(dāng)屬于基礎(chǔ)設(shè)施層，但是基礎(chǔ)設(shè)施層屬于最上層，如果放在基礎(chǔ)設(shè)施層，那么就會(huì)破壞依賴順序。因此我們?cè)谶壿媱澐稚峡梢园压ぞ哳悮w類為基礎(chǔ)設(shè)施或者通用域，在具體的工程結(jié)構(gòu)中，可以單獨(dú)一個(gè)模塊放工具類。

在實(shí)際工程中還有一種類型的代碼是配置相關(guān)的。從業(yè)務(wù)維度劃分的話可以分為業(yè)務(wù)類配置和基礎(chǔ)設(shè)施類配置。因此我們需要根據(jù)配置的類型將其放在對(duì)應(yīng)的位置。比如為了靈活應(yīng)對(duì)業(yè)務(wù)，我們通常會(huì)配置一個(gè)動(dòng)態(tài)開關(guān)，來動(dòng)態(tài)調(diào)整業(yè)務(wù)的邏輯，這種業(yè)務(wù)開關(guān)類的配置就應(yīng)該放在領(lǐng)域?qū)?；再比如?shù)據(jù)庫的配置屬于基礎(chǔ)設(shè)施配置，這類配置就應(yīng)當(dāng)放在基礎(chǔ)設(shè)施層。

2.4 我對(duì)于項(xiàng)目的六邊形架構(gòu)的實(shí)踐

我們團(tuán)隊(duì)做的的職責(zé)是業(yè)務(wù)底座，包含一系列的基礎(chǔ)能力建設(shè)。其中對(duì)于IDaaS系統(tǒng)而言，基于六邊形架構(gòu)實(shí)現(xiàn)出以下工程結(jié)構(gòu)：

三、repository模式

3.1 什么是repository模式？

在DDD思想中，repository表示資源庫的概念，用于區(qū)分?jǐn)?shù)據(jù)模型和領(lǐng)域模型。它操作的對(duì)象是聚合根，因此它屬于領(lǐng)域?qū)印?/p>

3.2 為什么要使用repository模式？

repository模式有兩個(gè)非常重要的作用：1、與底層存儲(chǔ)進(jìn)行解偶；2、為解決貧血模型提供了一種規(guī)范。

3.3 什么是貧血模型？

由于過去ER模型以及主流ORM框架的發(fā)展，讓很多開發(fā)者對(duì)實(shí)體的概念還停留在與關(guān)系形數(shù)據(jù)庫映射這個(gè)層面。從而導(dǎo)致實(shí)體只有空洞的屬性，而實(shí)體的業(yè)務(wù)邏輯散落各個(gè)service、util、helper、handler等各種角落中。這種現(xiàn)象就被稱為貧血模型現(xiàn)象。

如何判斷自己的工程是否有貧血模型現(xiàn)象？

1、大量的XxxDO或者Xxx：實(shí)體對(duì)象只包含與數(shù)據(jù)庫表映射的屬性，沒有行為或者及其少量的行為；

2、業(yè)務(wù)邏輯在各種service、controller、util、helper、handler中：實(shí)體的業(yè)務(wù)邏輯散落在不同層級(jí)、不同類、不同方法中，相似場(chǎng)景有大量的重復(fù)代碼。

3.4 為什么貧血模型不好？

無法保證實(shí)體對(duì)象的完整性和一致性：貧血模型下，實(shí)體屬性的狀態(tài)和值只能由調(diào)用方保證，但是屬性的get和set是公開的，因此所有調(diào)用方都可以調(diào)用。所以無法保證對(duì)象的完整性和一致性。

操作實(shí)體對(duì)象的邊界很難發(fā)現(xiàn)：由于對(duì)象只有屬性，屬性的邊界值、調(diào)用范圍不受實(shí)體自身控制，各個(gè)地方都可以調(diào)用，邊界值和范圍也只能由調(diào)用方自行保障。如果實(shí)體的邊界值有所變化，那么所有調(diào)用方都需要調(diào)整，這種情況下很容易導(dǎo)致bug的產(chǎn)生。

強(qiáng)依賴底層：貧血模型下的實(shí)體和數(shù)據(jù)庫模型映射、協(xié)議等。因此如果底層改變，那么上層邏輯需要全部跟著改變?！败浖弊兂闪恕肮碳?。

總結(jié)一句話：貧血模型下，軟件的可維護(hù)性、可擴(kuò)展性、可測(cè)試性極差！

擴(kuò)展： 軟件的可維護(hù)性=底層基礎(chǔ)設(shè)施變化時(shí)，需要新增/修改的代碼量是多少（越少可維護(hù)性越好） 軟件的可擴(kuò)展性=新增或變更業(yè)務(wù)邏輯時(shí)，需要新增/修改的代碼量是多少（越少可擴(kuò)展性越好） 軟件的可測(cè)試性=每條TC執(zhí)行的時(shí)長 * 新增或變更業(yè)務(wù)邏輯時(shí)產(chǎn)生的TC（時(shí)長越低/TC越少，測(cè)試性好）

3.5 實(shí)際情況中，為什么貧血模型難以消滅？

1、數(shù)據(jù)庫思維

隨著ER和ORM框架的發(fā)展，讓多數(shù)開發(fā)者在剛?cè)腴T的時(shí)候（自學(xué)、培訓(xùn)等方式），就認(rèn)為實(shí)體就是數(shù)據(jù)庫表映射；從而簡(jiǎn)單的將面向業(yè)務(wù)領(lǐng)域開發(fā)轉(zhuǎn)變成了面向數(shù)據(jù)庫開發(fā)，漸漸地就認(rèn)為軟件開發(fā)就是CRUD。

2、簡(jiǎn)單

盡管有些架構(gòu)師或者開發(fā)人員知道貧血模型不好，但是企業(yè)為了占領(lǐng)市場(chǎng)，需要快速推出產(chǎn)品。因此工期被壓縮的很厲害。而貧血模型恰好簡(jiǎn)單，在軟件初期階段，可以快速實(shí)現(xiàn)業(yè)務(wù)邏輯。從而迫使開發(fā)人員不得不“先實(shí)現(xiàn)了再說”。這種現(xiàn)象也是行業(yè)的普遍現(xiàn)象。

3、腳本思維

有些開發(fā)人員具備一定的抽象思維，將一些共性的代碼寫成util、helper、handler等類。但寫代碼依然是腳本思維。比如一個(gè)方法中，先來個(gè)字段校驗(yàn)代碼，再來個(gè)對(duì)象轉(zhuǎn)換代碼，然后調(diào)用遠(yuǎn)程服務(wù)，對(duì)遠(yuǎn)程服務(wù)返回的結(jié)果再來個(gè)對(duì)象轉(zhuǎn)換，……最后調(diào)用Dao類的方法保存對(duì)象。這種代碼在很多工程中太常見了。

基于這些因素，導(dǎo)致貧血模型難以消滅。

這些因素的根本原因是什么？

根本原因就是，大部分的開發(fā)人員混淆了數(shù)據(jù)模型和領(lǐng)域模型這兩個(gè)概念。

數(shù)據(jù)模型（Data Model）：數(shù)據(jù)模型解決的是數(shù)據(jù)如何持久化、如何傳輸?shù)膯栴}；

領(lǐng)域模型（Domin Model）：領(lǐng)域指的是某一個(gè)獨(dú)立的業(yè)務(wù)領(lǐng)域或者問題空間，領(lǐng)域模型就是解決這個(gè)業(yè)務(wù)領(lǐng)域或者問題空間而設(shè)計(jì)的模型；解決的是業(yè)務(wù)領(lǐng)域的問題。

在DDD中，repository就是用于區(qū)分?jǐn)?shù)據(jù)模型和領(lǐng)域模型提出來的概念。

3.6 使用repository之后，數(shù)據(jù)模型和領(lǐng)域模型如何轉(zhuǎn)換？

使用repository之后，數(shù)據(jù)模型和領(lǐng)域模型都各司其職。通過Assembler和Converter進(jìn)行模型之間的轉(zhuǎn)換。

在代碼中，動(dòng)態(tài)轉(zhuǎn)換映射 VS 靜態(tài)轉(zhuǎn)換映射

雖然Assembler/Converter是非常好用的對(duì)象，但是當(dāng)業(yè)務(wù)復(fù)雜時(shí)，手寫Assembler/Converter是一件耗時(shí)且容易出bug的事情，所以業(yè)界會(huì)有多種Bean Mapping的解決方案，從本質(zhì)上分為動(dòng)態(tài)和靜態(tài)映射。

動(dòng)態(tài)映射方案包括比較原始的 BeanUtils.copyProperties、能通過xml配置的Dozer等，其核心是在運(yùn)行時(shí)根據(jù)反射動(dòng)態(tài)賦值。動(dòng)態(tài)方案的缺陷在于大量的反射調(diào)用，性能比較差，內(nèi)存占用多，不適合特別高并發(fā)的應(yīng)用場(chǎng)景。而BeanUtils等copy類工具隱藏了內(nèi)部copy的過程，很容易引發(fā)bug且不易排查。

MapStruct通過注解，在編譯時(shí)靜態(tài)生成映射代碼，其最終編譯出來的代碼和手寫的代碼在性能上完全一致，且有強(qiáng)大的注解等能力。會(huì)節(jié)省大量的成本。

3.7 代碼層面模型規(guī)范和比較

3.8 代碼層面repository規(guī)范

1、接口名命名規(guī)范

repository中的接口名不要使用底層存儲(chǔ)的名稱（insert、update、add、delete、query等），而是盡量使用具有業(yè)務(wù)含義的命名。比如save、remove、find等。

2、接口的參數(shù)規(guī)范

repository操作的對(duì)象是聚合根。因此只能操作聚合根或者實(shí)體。這樣才能屏蔽底層的數(shù)據(jù)模型，避免數(shù)據(jù)模型滲透到領(lǐng)域?qū)印?/p>

四、領(lǐng)域?qū)釉O(shè)計(jì)規(guī)范

4.1 實(shí)體類

大多數(shù)DDD架構(gòu)的核心都是實(shí)體類，實(shí)體類包含了一個(gè)領(lǐng)域里的狀態(tài)、以及對(duì)狀態(tài)的直接操作。Entity最重要的設(shè)計(jì)原則是保證實(shí)體的不變性（Invariants），也就是說要確保無論外部怎么操作，一個(gè)實(shí)體內(nèi)部的屬性都不能出現(xiàn)相互沖突，狀態(tài)不一致的情況。

4.1.1 創(chuàng)建即一致

constructor參數(shù)要包含所有必要屬性，或者在constructor里有合理的默認(rèn)值。

4.1.2 使用Factory模式來降低調(diào)用方復(fù)雜度

由于創(chuàng)建即一致的原則，導(dǎo)致實(shí)體的構(gòu)造方法可能會(huì)很復(fù)雜，因此可以使用Factory模式來快速的構(gòu)造出一個(gè)新的實(shí)體。降低調(diào)用方的復(fù)雜度。

4.1.3 盡量避免public setter

一個(gè)最容易導(dǎo)致不一致性的原因是實(shí)體暴露了public的setter方法，特別是set單一參數(shù)會(huì)導(dǎo)致狀態(tài)不一致的情況。如果需要改變狀態(tài)，盡量語義化方法名稱。

4.1.4 通過聚合根保證主子實(shí)體的一致性

通常主實(shí)體會(huì)包含子實(shí)體，這時(shí)候主實(shí)體就需要起到聚合根的作用，即：

子實(shí)體不能單獨(dú)存在，只能通過聚合根的方法獲取到。任何外部的對(duì)象都不能直接保留子實(shí)體的引用

子實(shí)體沒有獨(dú)立的Repository，不可以單獨(dú)保存和取出，必須要通過聚合根的Repository實(shí)例化

子實(shí)體可以單獨(dú)修改自身狀態(tài)，但是多個(gè)子實(shí)體之間的狀態(tài)一致性需要聚合根來保障

exp：常見的電商域中聚合的案例如主子訂單模型、商品/SKU模型、跨子訂單優(yōu)惠、跨店優(yōu)惠模型等。

4.1.5 不可以強(qiáng)依賴其他聚合根實(shí)體或領(lǐng)域服務(wù)

一個(gè)實(shí)體的原則是高內(nèi)聚、低耦合，即一個(gè)實(shí)體類不能直接在內(nèi)部直接依賴一個(gè)外部的實(shí)體或服務(wù)。

對(duì)外部對(duì)象的依賴性會(huì)直接導(dǎo)致實(shí)體無法被單測(cè)； 以及一個(gè)實(shí)體無法保證外部實(shí)體變更后不會(huì)影響本實(shí)體的一致性和正確性。

正確依賴外部的方式

只保存外部實(shí)體的ID：這里我再次強(qiáng)烈建議使用強(qiáng)類型的ID對(duì)象，而不是Long型ID。強(qiáng)類型的ID對(duì)象不單單能自我包含驗(yàn)證代碼，保證ID值的正確性，同時(shí)還能確保各種入?yún)⒉粫?huì)因?yàn)閰?shù)順序變化而出bug。

針對(duì)于“無副作用”的外部依賴，通過方法入?yún)⒌姆绞絺魅?。比如上文中的equip(Weapon，EquipmentService）方法。

4.1.6 任何實(shí)體的行為只能直接影響到本實(shí)體（和其子實(shí)體）

這個(gè)原則更多是一個(gè)確保代碼可讀性、可理解的原則，即任何實(shí)體的行為不能有“直接”的”副作用“，即直接修改其他的實(shí)體類。這么做的好處是代碼讀下來不會(huì)產(chǎn)生意外。

另一個(gè)遵守的原因是可以降低未知的變更的風(fēng)險(xiǎn)。在一個(gè)系統(tǒng)里一個(gè)實(shí)體對(duì)象的所有變更操作應(yīng)該都是預(yù)期內(nèi)的，如果一個(gè)實(shí)體能隨意被外部直接修改的話，會(huì)增加代碼bug的風(fēng)險(xiǎn)。

4.1.7 可以利用enum來代替繼承關(guān)系，后續(xù)也可以利用Type Object設(shè)計(jì)模式來做到數(shù)據(jù)驅(qū)動(dòng)

4.2 領(lǐng)域服務(wù)

當(dāng)一個(gè)業(yè)務(wù)邏輯需要用到多個(gè)領(lǐng)域?qū)ο笞鳛檩斎?，輸出結(jié)果是一個(gè)值對(duì)象時(shí)，就說明需要使用到領(lǐng)域服務(wù)。

4.2.1 單對(duì)象策略型

這種領(lǐng)域?qū)ο笾饕嫦虻氖菃蝹€(gè)實(shí)體對(duì)象的變更，但涉及到多個(gè)領(lǐng)域?qū)ο蠡蛲獠恳蕾嚨囊恍┮?guī)則。

在這種類型下，實(shí)體應(yīng)該通過方法入?yún)⒌姆绞絺魅脒@種領(lǐng)域服務(wù)，然后通過Double Dispatch來反轉(zhuǎn)調(diào)用領(lǐng)域服務(wù)的方法。

什么是Double Dispatch

exp：對(duì)于“玩家”實(shí)體而言，有一個(gè)“equip()”裝備武器的方法。 按照常規(guī)思路，“玩家”實(shí)體需要注入一個(gè)EquipmentService，然而實(shí)體只能保留自己的狀態(tài)， 除此之外的其他對(duì)象實(shí)體無法保證其完整性，因此我們不通過注入的方式使用EquipmentService； 而是通過方法參數(shù)引入的方式來使用。即“玩家”實(shí)體的"equip()"方法定義為： public void equip(Weapon weapon, EquipmentService equipmentService) { if(equipmentService.canEquip(this, weapon)) { this.weaponId = weapon.getId(); } } 這種方式就稱為Double Dispatch方式。 Double Dispatch是一個(gè)使用Domain Service經(jīng)常會(huì)用到的方法，類似于調(diào)用反轉(zhuǎn)。

4.2.2 跨對(duì)象事務(wù)型

當(dāng)一個(gè)行為會(huì)直接修改多個(gè)實(shí)體時(shí)，不能再通過單一實(shí)體的方法作處理，而必須直接使用領(lǐng)域服務(wù)的方法來做操作。在這里，領(lǐng)域服務(wù)更多的起到了跨對(duì)象事務(wù)的作用，確保多個(gè)實(shí)體的變更之間是有一致性的。

4.2.3 通用組件型

這種類型的領(lǐng)域服務(wù)提供了組件化的行為，但本身又不直接綁死在一種實(shí)體類上。他的好處是可以通過組件化服務(wù)降低代碼的重復(fù)性。

接口組件化來實(shí)現(xiàn)通用領(lǐng)域服務(wù)

exp：在游戲系統(tǒng)中，原價(jià)、NPC、怪物都是可移動(dòng)的。因此可以設(shè)計(jì)一個(gè)Movable接口， 讓玩家、NPC、怪物實(shí)體實(shí)現(xiàn)Movable接口。然后再實(shí)現(xiàn)一個(gè)MoveService，從而實(shí)現(xiàn)一個(gè)移動(dòng)通用服務(wù)。

4.3 策略對(duì)象（Domain Policy）

Policy或者Strategy設(shè)計(jì)模式是一個(gè)通用的設(shè)計(jì)模式，但是在DDD架構(gòu)中會(huì)經(jīng)常出現(xiàn)，其核心就是封裝領(lǐng)域規(guī)則。

一個(gè)Policy是一個(gè)無狀態(tài)的單例對(duì)象，通常需要至少2個(gè)方法：canApply 和 一個(gè)業(yè)務(wù)方法。

canApply方法用來判斷一個(gè)Policy是否適用于當(dāng)前的上下文，如果適用則調(diào)用方會(huì)去觸發(fā)業(yè)務(wù)方法。 通常，為了降低一個(gè)Policy的可測(cè)試性和復(fù)雜度，Policy不應(yīng)該直接操作對(duì)象，而是通過返回計(jì)算后的值， 在Domain Service里對(duì)對(duì)象進(jìn)行操作。

4.4 副作用的處理方法 - 領(lǐng)域事件

什么是副作用？

“副作用”也是一種領(lǐng)域規(guī)則。一般的副作用發(fā)生在核心領(lǐng)域模型狀態(tài)變更后，同步或者異步對(duì)另一個(gè)對(duì)象的影響或行為。比如：當(dāng)用于積分達(dá)到100時(shí)，會(huì)員等級(jí)升1級(jí)。

在DDD中，解決“副作用”的手段是領(lǐng)域事件。通過EventBus事件總線可以實(shí)現(xiàn)領(lǐng)域事件的傳播。

目前領(lǐng)域事件的缺陷和展望

由于實(shí)體需要保證完整性，因此不能夠直接依賴EventBus，所以EventBus只能保持全局singleton。但是全局singleton對(duì)象很難被單測(cè)，這就容易導(dǎo)致Entity對(duì)象很難被完整單測(cè)覆蓋全。

五、寫在最后

通過對(duì)于DDD的學(xué)習(xí)與實(shí)踐，越來越能夠體會(huì)到它作為一種軟件設(shè)計(jì)思想和指導(dǎo)，對(duì)于大型復(fù)雜軟件的建設(shè)十分有幫助。對(duì)于歷史遺留屎山工程的重構(gòu)也提供了一個(gè)很好的指導(dǎo)方向。

審核編輯 黃宇