若遵循基于面向?qū)ο笤O(shè)計(jì)范式的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)，并用以應(yīng)對(duì)紛繁復(fù)雜的業(yè)務(wù)邏輯，則強(qiáng)調(diào)領(lǐng)域模型的充血設(shè)計(jì)模型已成為社區(qū)不爭(zhēng)事實(shí)。我將Eric提及的戰(zhàn)術(shù)設(shè)計(jì)要素如Entity、Value Object、Domain Service、Aggregate、Repository與Factory視為設(shè)計(jì)模型。這其中，只有Entity、Value Object和Domain Service才能表達(dá)領(lǐng)域邏輯。

?

為避免貧血模型，在封裝領(lǐng)域邏輯時(shí)，考慮設(shè)計(jì)要素的順序?yàn)椋?/p>

Value Object -》 Entity -》 Domain Service

切記，我們必須將Domain Service作為承擔(dān)業(yè)務(wù)邏輯的最后的救命稻草。之所以把Domain Service放在最后，是因?yàn)槲姨宄I(lǐng)域服務(wù)的強(qiáng)大“魔力”了。開(kāi)發(fā)人員總會(huì)有一種惰性，很多時(shí)候不愿意仔細(xì)思考所謂“職責(zé)（封裝領(lǐng)域邏輯的行為）”的正確履行者，而領(lǐng)域服務(wù)恰恰是最便捷的選擇。

就我個(gè)人的理解，只有滿(mǎn)足如下三個(gè)特征的領(lǐng)域行為才應(yīng)該放到領(lǐng)域服務(wù)中：

領(lǐng)域行為需要多個(gè)領(lǐng)域?qū)嶓w參與協(xié)作

領(lǐng)域行為與狀態(tài)無(wú)關(guān)

領(lǐng)域行為需要與外部資源（尤其是DB）協(xié)作

假設(shè)某系統(tǒng)的合同管理功能允許客戶(hù)輸入自編碼，該自編碼需要遵循一定的編碼格式。在創(chuàng)建新合同時(shí)，客戶(hù)輸入自編碼，系統(tǒng)需要檢測(cè)該自編碼是否在已有合同中已經(jīng)存在。針對(duì)該需求，可以提煉出兩個(gè)領(lǐng)域行為：

驗(yàn)證輸入的自編碼是否符合業(yè)務(wù)規(guī)則

檢查自編碼是否重復(fù)

在尋找職責(zé)的履行者時(shí)，我們應(yīng)首先遵循“信息專(zhuān)家模式”，即“擁有信息的對(duì)象就是操作該信息的專(zhuān)家”，因此可以提出一個(gè)問(wèn)題：領(lǐng)域行為要操作的數(shù)據(jù)由誰(shuí)擁有？針對(duì)第一個(gè)領(lǐng)域行為，就是要確認(rèn)誰(shuí)擁有自編碼格式的驗(yàn)證規(guī)則？有兩個(gè)候選：

擁有自編碼信息的“合同（Contract）”對(duì)象

體現(xiàn)自編碼知識(shí)概念自身的“自編碼（CustomizedNumber）”對(duì)象

我傾向于定義CustomizedNumber值對(duì)象，將該檢測(cè)規(guī)則封裝其內(nèi)，并在構(gòu)造函數(shù)中對(duì)其進(jìn)行驗(yàn)證。在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中，值對(duì)象往往用于封裝這些基礎(chǔ)概念。由于自定義的類(lèi)型可以封裝領(lǐng)域行為，就可以有效地實(shí)現(xiàn)職責(zé)的“分治”，實(shí)現(xiàn)對(duì)象的協(xié)作。

若要檢查自編碼是否重復(fù)，則需要從數(shù)據(jù)庫(kù)中查找，這就需要通過(guò)Repository與DB協(xié)作?；谇懊婵偨Y(jié)的三個(gè)特征，則該職責(zé)應(yīng)該分配給一個(gè)領(lǐng)域服務(wù)，例如DuplicatedNumberChecker。

從職責(zé)分配的角度看，實(shí)體Contract又或者值對(duì)象CustomizedNumber才應(yīng)該是承擔(dān)該職責(zé)的合理選擇。為何我卻定義了這么一條例外原則呢？究其原因，就是在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中，我們應(yīng)盡量保證實(shí)體與值對(duì)象的純粹性，尤其不應(yīng)該依賴(lài)于Repository（資源庫(kù)）。繼續(xù)深挖根本原因，是因?yàn)閷?shí)體與值對(duì)象的生命周期是由Repository管理的。倘若被管理的實(shí)體對(duì)象還依賴(lài)了Repository，就要求該實(shí)體對(duì)應(yīng)的Repository在管理實(shí)體對(duì)象的生命周期的同時(shí)，還需要管理它與Repository的依賴(lài)，這并不合理。值對(duì)象在一個(gè)聚合（Aggregate）邊界之內(nèi)，道理相同。

舉例來(lái)說(shuō)，假設(shè)Contract是聚合根，如果將檢查重復(fù)編碼的職責(zé)分配給該實(shí)體對(duì)象（或值對(duì)象CustomizedNumber），內(nèi)部就需要依賴(lài)ContractRepository。然而，Contract的獲取也是通過(guò)Repository得到，在基礎(chǔ)設(shè)施層對(duì)ContractRepository的實(shí)現(xiàn)時(shí)，其實(shí)并不知道該如何管理二者之間的依賴(lài)。如果Contract實(shí)體還要依賴(lài)其他Repository，就更不可能了。

若真要解決此依賴(lài)管理問(wèn)題，較簡(jiǎn)單的做法是為Contract提供一個(gè)setContractRepository（）的依賴(lài)注入方法。不過(guò)，當(dāng)Contract是通過(guò)Repository來(lái)獲得時(shí)，如Spring、Guice之類(lèi)的DI框架都無(wú)法注入這一依賴(lài)，因而需要顯式調(diào)用，這就會(huì)引入對(duì)Repository具體實(shí)現(xiàn)的耦合。這樣的耦合放在領(lǐng)域?qū)?，?huì)導(dǎo)致本來(lái)單純的領(lǐng)域?qū)觾?nèi)核依賴(lài)了外部資源。倘若將這種具體耦合往外推，例如推到應(yīng)用層，又會(huì)加重調(diào)用者的負(fù)擔(dān)。

領(lǐng)域服務(wù)則不存在此問(wèn)題，因?yàn)樗纳芷诓皇怯蒖epository管理。如下的領(lǐng)域服務(wù)定義是合情合理的：

我們?cè)诜峙漕I(lǐng)域邏輯時(shí)，領(lǐng)域服務(wù)是最輕易也是最便宜的首選。這會(huì)導(dǎo)致領(lǐng)域服務(wù)的泛濫，長(zhǎng)此以往，對(duì)領(lǐng)域?qū)拥拈_(kāi)發(fā)又會(huì)走向“貧血模型”的老路。所謂“服務(wù)”本身就是一個(gè)抽象概念。越抽象就越顯得包容并蓄。例如定義一個(gè)OrderService，那么所有和訂單有關(guān)的邏輯都可以往這個(gè)服務(wù)里面塞，而諸如Order之類(lèi)的實(shí)體對(duì)象終歸有不少限制，分配職責(zé)時(shí)需得思慮再三。因此，倘若在設(shè)計(jì)與開(kāi)發(fā)時(shí)對(duì)職責(zé)的分配不加約束，所謂的“職責(zé)分治”就不過(guò)是一句空話(huà)罷了。

歸根結(jié)底，主流的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)在戰(zhàn)術(shù)層面考察的其實(shí)是面向?qū)ο蟮脑O(shè)計(jì)能力。我認(rèn)為，所謂面向?qū)ο笤O(shè)計(jì)，核心就是角色、職責(zé)與協(xié)作。在分配職責(zé)時(shí)，應(yīng)考慮將數(shù)據(jù)與行為封裝在一起，這是面向?qū)ο笤O(shè)計(jì)的首要原則。

為了避免程序員把領(lǐng)域服務(wù)當(dāng)做一個(gè)“筐”，什么邏輯都往里面裝，除了需要提高團(tuán)隊(duì)成員面向?qū)ο蟮脑O(shè)計(jì)能力，并加強(qiáng)代碼評(píng)審之外，還有一個(gè)方法，就是對(duì)領(lǐng)域服務(wù)加以約束。

沒(méi)有任何語(yǔ)言可以在DDD設(shè)計(jì)要素上施加約束。Mat Wall與Nik Silver在對(duì)Guardian.co.uk網(wǎng)站推行DDD時(shí)的實(shí)踐值得我們借鑒。他們?cè)谖恼隆堆葸M(jìn)架構(gòu)中的領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》中建議：

為了對(duì)付這一行為，我們對(duì)應(yīng)用中的所有服務(wù)進(jìn)行了代碼評(píng)審，并進(jìn)行重構(gòu)，將邏輯移到適當(dāng)?shù)念I(lǐng)域?qū)ο笾?。我們還制定了一個(gè)新的規(guī)則：任何服務(wù)對(duì)象在其名稱(chēng)中必須包含一個(gè)動(dòng)詞。這一簡(jiǎn)單的規(guī)則阻止了開(kāi)發(fā)人員去創(chuàng)建類(lèi)似于A(yíng)rticleService的類(lèi)。取而代之，我們創(chuàng)建 ArticlePublishingService和ArticleDeletionService這樣的類(lèi)。推動(dòng)這一簡(jiǎn)單的命名規(guī)范的確幫助我們將領(lǐng)域邏輯移到了正確的地方，但我們?nèi)砸髮?duì)服務(wù)進(jìn)行定期的代碼評(píng)審，以確保我們?cè)谡壣?，以及?duì)領(lǐng)域的建模接近于實(shí)際的業(yè)務(wù)觀(guān)點(diǎn)。

其實(shí)，這一別具一格的約束形式其實(shí)與服務(wù)的本質(zhì)是一脈相承的，即服務(wù)應(yīng)代表無(wú)狀態(tài)的領(lǐng)域行為，甚至可以說(shuō)領(lǐng)域服務(wù)是領(lǐng)域?qū)用嬗美捏w現(xiàn)。

這一實(shí)踐可能會(huì)導(dǎo)致更多細(xì)粒度的領(lǐng)域服務(wù)產(chǎn)生，但更有可能的結(jié)果是，當(dāng)我們?cè)趧?chuàng)建一個(gè)新的領(lǐng)域服務(wù)時(shí)，可能會(huì)考慮暫時(shí)停下來(lái)，想一想，要分配給這個(gè)新服務(wù)的領(lǐng)域邏輯是否有更好的去處呢？即使因?yàn)樵撨壿嬁赡軤可娴蕉鄠€(gè)領(lǐng)域?qū)嶓w，又或者需要與Repository協(xié)作而不得不放入到領(lǐng)域服務(wù)中，似乎也可以考慮將領(lǐng)域邏輯中與實(shí)體（或值對(duì)象）數(shù)據(jù)強(qiáng)相關(guān)的內(nèi)容”摘“出來(lái)，分配到合適的地方，保證職責(zé)分配的合理均衡。和諧的協(xié)作機(jī)制是好的面向?qū)ο笤O(shè)計(jì)。