要基于這一標(biāo)準(zhǔn)對(duì)應(yīng)用服務(wù)與領(lǐng)域服務(wù)做出正確判斷，更多地還是依靠你對(duì)設(shè)計(jì)的感覺(jué)。因?yàn)閮r(jià)值與功能在不同的層次會(huì)產(chǎn)生一種層層遞進(jìn)的遞歸關(guān)系。例如下訂單是業(yè)務(wù)價(jià)值，驗(yàn)證訂單就是實(shí)現(xiàn)該業(yè)務(wù)價(jià)值的業(yè)務(wù)功能；然而再進(jìn)一層，又可以將驗(yàn)證訂單視為業(yè)務(wù)價(jià)值，而將驗(yàn)證訂單的配送地址有效性作為實(shí)現(xiàn)該業(yè)務(wù)價(jià)值的業(yè)務(wù)功能。至于前面提到的“任務(wù)編制”，其實(shí)也存在歧義，即使在領(lǐng)域服務(wù)中，也存在任務(wù)編制的可能，這實(shí)際取決于你對(duì)任務(wù)層次的定位。這還真是剪不斷理還亂了。

讓我們回歸本質(zhì)，回到對(duì)“領(lǐng)域”這個(gè)詞的理解。在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)這個(gè)大背景下，領(lǐng)域其實(shí)與軟件系統(tǒng)服務(wù)的行業(yè)有關(guān)，如金融行業(yè)、制造行業(yè)、醫(yī)療行業(yè)、教育行業(yè)等。在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)的戰(zhàn)略階段，又將整個(gè)系統(tǒng)的領(lǐng)域分解為核心領(lǐng)域與子領(lǐng)域，它們解決的是不同的問(wèn)題域。在解決方案域，應(yīng)用服務(wù)和領(lǐng)域服務(wù)都屬于一個(gè)具體的限界上下文，它們又必然映射到問(wèn)題域中某一個(gè)子領(lǐng)域上。由此可得到一個(gè)推論：領(lǐng)域邏輯就是對(duì)應(yīng)子領(lǐng)域包含的業(yè)務(wù)知識(shí)和業(yè)務(wù)規(guī)則，應(yīng)用邏輯則是為了完成完整用例而包含的除領(lǐng)域邏輯之外的其他業(yè)務(wù)邏輯，包括作為基礎(chǔ)架構(gòu)問(wèn)題的橫切關(guān)注點(diǎn)，也可能包含對(duì)非領(lǐng)域知識(shí)相關(guān)的處理邏輯，如對(duì)輸入、輸出格式的轉(zhuǎn)換等。

Eric Evans 用銀行轉(zhuǎn)賬的案例來(lái)講解應(yīng)用邏輯與領(lǐng)域邏輯的差異。他說(shuō)：“資金轉(zhuǎn)賬在銀行領(lǐng)域語(yǔ)言中是一項(xiàng)有意義的操作，而且它涉及基本的業(yè)務(wù)邏輯?！边@就說(shuō)明資金轉(zhuǎn)賬屬于領(lǐng)域邏輯。至于應(yīng)用服務(wù)該做什么，他又說(shuō)道：“如果銀行應(yīng)用程序可以把我們的交易進(jìn)行轉(zhuǎn)換并導(dǎo)出到一個(gè)電子表格文件中，以便進(jìn)行分析，那么這個(gè)導(dǎo)出操作就是應(yīng)用服務(wù)。‘文件格式’在銀行領(lǐng)域中是沒(méi)有意義的，它也不涉及業(yè)務(wù)規(guī)則?！?/p>

因此，到底選擇應(yīng)用服務(wù)還是領(lǐng)域服務(wù)，就看它的實(shí)現(xiàn)中到底是應(yīng)用邏輯的范疇，還是領(lǐng)域邏輯的范疇。一個(gè)簡(jiǎn)單的判斷標(biāo)準(zhǔn)在于這段代碼蘊(yùn)含的知識(shí)是否與它所處的限界上下文要解決的問(wèn)題域直接有關(guān)？如此說(shuō)來(lái)，針對(duì)“下訂單”用例而言，在前面列出的四個(gè)領(lǐng)域行為中，只有“發(fā)送郵件”與購(gòu)買(mǎi)子領(lǐng)域沒(méi)有關(guān)系，因此可考慮將其作為要編制的任務(wù)放到應(yīng)用服務(wù)中。如此推導(dǎo)出來(lái)的訂單應(yīng)用服務(wù)實(shí)現(xiàn)為：

public class OrderAppService {@Serviceprivate PlacingOrderService placingOrderService;// 此時(shí)將 NotificationService 視為基礎(chǔ)設(shè)施服務(wù)@Serviceprivate NotificationService notificationService;// 事務(wù)為橫切關(guān)注點(diǎn)@Transactional(propagation=Propagation.REQUIRED) public void placeOrder(Order order) { try {orderService.execute(order);notificationService.send(notificationComposer.compose(order));} catch (InvalidOrderException ex | Exception ex) {// 日志為橫切關(guān)注點(diǎn)logger.error(ex.getMessage());// ApplicationException 派生自 RuntimeException，事務(wù)會(huì)在拋出該異常時(shí)回滾throw new ApplicationException("failed to place order", ex);}}
}

即使如此，應(yīng)用邏輯與領(lǐng)域邏輯的邊界線依舊微妙難分。

我注意到《領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)》中的兩段描述。其一：

很多領(lǐng)域服務(wù)或應(yīng)用服務(wù)是在實(shí)體和值對(duì)象的基礎(chǔ)上建立起來(lái)的，它們的行為類似于將領(lǐng)域的一些潛在功能組織起來(lái)以執(zhí)行某種任務(wù)的腳本。實(shí)體和值對(duì)象往往由于粒度過(guò)細(xì)而無(wú)法提供對(duì)領(lǐng)域?qū)庸δ艿谋憬菰L問(wèn)。

其二：

在大型系統(tǒng)中，中等粒度的、無(wú)狀態(tài)的服務(wù)更容易被復(fù)用，因?yàn)樗鼈冊(cè)诤?jiǎn)單的接口背后封裝了重要的功能?！捎趹?yīng)用層負(fù)責(zé)對(duì)領(lǐng)域?qū)ο蟮男袨檫M(jìn)行協(xié)調(diào)，因此細(xì)粒度的領(lǐng)域?qū)ο罂赡軙?huì)把領(lǐng)域?qū)拥闹R(shí)泄露到應(yīng)用層中。這產(chǎn)生的結(jié)果是應(yīng)用層不得不處理復(fù)雜的、細(xì)致的交互，從而使得領(lǐng)域知識(shí)蔓延到應(yīng)用層或用戶界面代碼當(dāng)中，而領(lǐng)域?qū)訒?huì)丟失這些知識(shí)。明智地引入領(lǐng)域服務(wù)有助于在應(yīng)用層和領(lǐng)域?qū)又g保持一條明確的界限。

綜合這兩段話，我們可以隱約探索到分辨應(yīng)用服務(wù)與領(lǐng)域服務(wù)的真相。第一段提到“實(shí)體和值對(duì)象往往由于粒度過(guò)細(xì)而無(wú)法提供對(duì)領(lǐng)域?qū)庸δ艿谋憬菰L問(wèn)”，第二段又提到“細(xì)粒度的領(lǐng)域?qū)ο罂赡軙?huì)把領(lǐng)域?qū)拥闹R(shí)泄露到應(yīng)用層中”，無(wú)論從隱藏細(xì)節(jié)的角度，還是從便捷訪問(wèn)的角度，在領(lǐng)域?qū)?#xff0c;領(lǐng)域服務(wù)都成了當(dāng)仁不讓的最佳選擇。

而在第一段中，Eric Evans 又說(shuō)應(yīng)用服務(wù)和領(lǐng)域服務(wù)都是“執(zhí)行某種任務(wù)的腳本”。任務(wù)腳本可以理解為對(duì)任務(wù)的編制，只是應(yīng)用服務(wù)和領(lǐng)域服務(wù)處理的任務(wù)層級(jí)并不相同罷了。再結(jié)合第二段的最后一句“明智地引入領(lǐng)域服務(wù)有助于在應(yīng)用層和領(lǐng)域?qū)又g保持一條明確的界限”，我們有理由得到如下結(jié)論：

• 細(xì)粒度的領(lǐng)域?qū)ο蟀▽?shí)體、值對(duì)象以及領(lǐng)域服務(wù)，但為了避免領(lǐng)域?qū)又R(shí)泄漏到應(yīng)用層中，應(yīng)在領(lǐng)域?qū)佣x中等粒度的領(lǐng)域服務(wù)，它的實(shí)現(xiàn)可以認(rèn)為是對(duì)細(xì)粒度領(lǐng)域服務(wù)、聚合的任務(wù)編制
• 理想狀態(tài)下，應(yīng)用服務(wù)應(yīng)該只與中等粒度的領(lǐng)域服務(wù)協(xié)作，它對(duì)任務(wù)的編制，實(shí)則就是對(duì)領(lǐng)域服務(wù)的編制

若同意這一結(jié)論，說(shuō)明應(yīng)用服務(wù)中只能包含兩部分內(nèi)容：領(lǐng)域服務(wù)、橫切關(guān)注點(diǎn)。如此設(shè)計(jì)自然逃脫不了僵化的嫌疑，但殊不知我是在為設(shè)計(jì)做減法。若設(shè)計(jì)者能夠充分辨別應(yīng)用邏輯與領(lǐng)域邏輯之間的差別，突破這一約束也未嘗不可。一旦你擁有了足夠豐富的設(shè)計(jì)知識(shí)和設(shè)計(jì)經(jīng)驗(yàn)，就意味著你可以正確地做出適合當(dāng)前場(chǎng)景的設(shè)計(jì)決策與判斷。若無(wú)法做到，不妨從一些相對(duì)固化的簡(jiǎn)單原則開(kāi)始做起，這算是從新手到專家所必須經(jīng)歷的成長(zhǎng)過(guò)程。

影響應(yīng)用服務(wù)的因素

一旦對(duì)應(yīng)用服務(wù)的設(shè)計(jì)進(jìn)行了約束，要分辨應(yīng)用服務(wù)和領(lǐng)域服務(wù)的區(qū)別就變得容易了許多。然而，軟件設(shè)計(jì)就是這樣，當(dāng)你因?yàn)槟撤N干擾因素而做出一種設(shè)計(jì)決策時(shí)，在消除了這一干擾因素的同時(shí)，另外一些原來(lái)不曾顯現(xiàn)的干擾因素又可能浮現(xiàn)出來(lái)。既然應(yīng)用服務(wù)的實(shí)現(xiàn)代碼只能包含橫切關(guān)注點(diǎn)，也只能與領(lǐng)域?qū)拥念I(lǐng)域服務(wù)協(xié)作，那就需要我們對(duì)橫切關(guān)注點(diǎn)做出正確判斷，同時(shí)還需要明確領(lǐng)域服務(wù)的設(shè)計(jì)粒度。

橫切關(guān)注點(diǎn)的判斷

要判斷一個(gè)服務(wù)是否為應(yīng)用服務(wù)，需要明確什么是“橫切關(guān)注點(diǎn)”。前面已經(jīng)明確給出了“橫切關(guān)注點(diǎn)”的定義，但是，在判斷橫切關(guān)注點(diǎn)以及整合橫切關(guān)注點(diǎn)時(shí)，除了前面提到的事務(wù)、監(jiān)控、身份驗(yàn)證與授權(quán)沒(méi)有爭(zhēng)議之外，社區(qū)對(duì)如下關(guān)注點(diǎn)普遍存在困惑與糾結(jié)。

日志

毫無(wú)疑問(wèn)，日志屬于橫切關(guān)注點(diǎn)的范疇。然而，倘若將日志功能僅僅放在應(yīng)用層，又可能無(wú)法準(zhǔn)確詳細(xì)地記錄操作行為與錯(cuò)誤信息。很多語(yǔ)言都提供了基礎(chǔ)的日志框架，將日志混雜在領(lǐng)域?qū)ο笾?#xff0c;會(huì)影響領(lǐng)域的純粹性，也帶來(lái)了系統(tǒng)與日志框架的耦合，除非采用 AOP 的方式。目前看來(lái)，這是一種編碼取舍，即傾向于代碼的純粹性，還是代碼的高質(zhì)量。我個(gè)人更看重代碼的質(zhì)量，尤其是豐富的日志內(nèi)容有助于運(yùn)維排錯(cuò)，因此可考慮將作為橫切關(guān)注點(diǎn)之一的日志功能放在領(lǐng)域服務(wù)中，算是上述應(yīng)用服務(wù)邊界定義的特例。

當(dāng)然，這個(gè)劃分并非排他性的。在應(yīng)用服務(wù)中，同樣需要調(diào)用日志功能，只是記錄的信息與粒度和領(lǐng)域服務(wù)不盡相同罷了。

驗(yàn)證

如果是驗(yàn)證外部客戶傳遞過(guò)來(lái)的消息，例如對(duì) RESTful 服務(wù)的 Request 請(qǐng)求的驗(yàn)證，則該驗(yàn)證功能屬于橫切關(guān)注點(diǎn)，對(duì)它的調(diào)用就應(yīng)該放在應(yīng)用服務(wù)（亦可考慮由遠(yuǎn)程服務(wù)自己承擔(dān)）。如果驗(yàn)證邏輯屬于一種業(yè)務(wù)規(guī)則，例如驗(yàn)證訂單有效性，就應(yīng)該將驗(yàn)證邏輯放在領(lǐng)域?qū)?#xff0c;以便于領(lǐng)域模型對(duì)象調(diào)用。

異常處理

與領(lǐng)域邏輯有關(guān)的錯(cuò)誤與異常，應(yīng)該以自定義異常形式表達(dá)業(yè)務(wù)含義，并被定義在領(lǐng)域?qū)?。此?#xff0c;如果該異常表達(dá)了業(yè)務(wù)含義，為了保證業(yè)務(wù)的健壯性，可在領(lǐng)域?qū)又袑惓６x為受控異常（Checked Exception）。由于該異常與業(yè)務(wù)有關(guān)，即使被定義在方法接口中，也不存在異常對(duì)接口的污染，即可以將異常視為接口契約的一部分。但是，在領(lǐng)域服務(wù)中，不應(yīng)該將與業(yè)務(wù)無(wú)關(guān)的受控異常定義在領(lǐng)域服務(wù)的方法中，否則就會(huì)導(dǎo)致業(yè)務(wù)邏輯與技術(shù)實(shí)現(xiàn)的混合。

在應(yīng)用層，應(yīng)盡可能保證應(yīng)用服務(wù)的通用性，因而需要在應(yīng)用服務(wù)中捕獲與業(yè)務(wù)有關(guān)的自定義異常，然后將其轉(zhuǎn)換為標(biāo)準(zhǔn)格式的異常之后再拋出。例如，可統(tǒng)一定義為應(yīng)用層的標(biāo)準(zhǔn)異常 ApplicationException，然后在 message 或 cause 中包含具體的業(yè)務(wù)含義。因此，針對(duì)異常處理，只有這部分與業(yè)務(wù)無(wú)關(guān)的處理與轉(zhuǎn)換功能，才屬于橫切關(guān)注點(diǎn)的范疇，并放在應(yīng)用層，其余異常處理邏輯都屬于領(lǐng)域?qū)印?/p>

基礎(chǔ)設(shè)施服務(wù)

除了上述糾結(jié)的橫切關(guān)注點(diǎn)之外，我們還要注意基礎(chǔ)設(shè)施服務(wù)與橫切關(guān)注點(diǎn)之間的區(qū)別。在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中，基礎(chǔ)設(shè)施服務(wù)作為技術(shù)服務(wù)，被定義為網(wǎng)關(guān)。從代碼實(shí)現(xiàn)的角度考慮，南向網(wǎng)關(guān)代表了一個(gè)內(nèi)聚的技術(shù)實(shí)現(xiàn)，可以被抽象為接口；橫切關(guān)注點(diǎn)則是一些鉤子方法，會(huì)在領(lǐng)域行為方法的前后被執(zhí)行，因此難以抽象為接口。顯然，基礎(chǔ)設(shè)施服務(wù)就像提供的其他基礎(chǔ)功能一般，可以很容易被重用，而橫切關(guān)注點(diǎn)由于會(huì)和領(lǐng)域邏輯糾纏在一起，很難剝離出單獨(dú)的橫切關(guān)注點(diǎn)代碼，除非采用面向切面編程。

遵循應(yīng)用服務(wù)的設(shè)計(jì)原則，它除了和領(lǐng)域服務(wù)進(jìn)行協(xié)作之外，就只是包含了橫切關(guān)注點(diǎn)，這就說(shuō)明應(yīng)用服務(wù)甚至都不應(yīng)該依賴于提供基礎(chǔ)設(shè)施服務(wù)的南向網(wǎng)關(guān)。這樣的設(shè)計(jì)約束充分保證了應(yīng)用服務(wù)的簡(jiǎn)單性。因此，只要判斷某個(gè)邏輯屬于基礎(chǔ)設(shè)施服務(wù)，就應(yīng)該首先考慮與領(lǐng)域服務(wù)協(xié)作，而非應(yīng)用服務(wù)。例如，郵件通知服務(wù)就屬于典型的基礎(chǔ)設(shè)施服務(wù)。既然如此，針對(duì)訂單應(yīng)用服務(wù)的實(shí)現(xiàn)，就應(yīng)該將通知服務(wù)轉(zhuǎn)移到 PlacingOrderService 領(lǐng)域服務(wù)中。事實(shí)上，在前面修改后的訂單應(yīng)用服務(wù)代碼中，代碼 notificationComposer.compose(order) 放在應(yīng)用服務(wù)中本身也不太合適，因?yàn)閷⒂唵蝺?nèi)容轉(zhuǎn)換為郵件通知內(nèi)容，更像是領(lǐng)域邏輯，而非應(yīng)用邏輯。

領(lǐng)域服務(wù)的設(shè)計(jì)粒度

在領(lǐng)域?qū)又?#xff0c;為了保證聚合內(nèi)部實(shí)體與值對(duì)象的純粹性，我們將與外部資源抽象之間的協(xié)作推給了領(lǐng)域服務(wù)；為了避免出現(xiàn)貧血模型和過(guò)程式的事務(wù)腳本，我們要求定義帶有動(dòng)詞的領(lǐng)域服務(wù)，使得領(lǐng)域服務(wù)在正確表達(dá)領(lǐng)域行為特征的同時(shí)，粒度也變得更細(xì)。這時(shí)的領(lǐng)域服務(wù)其本質(zhì)更像是一個(gè)函數(shù)，沒(méi)有狀態(tài)，單一職責(zé)，體現(xiàn)的是領(lǐng)域邏輯的行為特征。

但是，在面向?qū)ο笤O(shè)計(jì)中，粒度大小與簡(jiǎn)單設(shè)計(jì)需要平衡。若要二者兼得，需要在細(xì)粒度對(duì)象之上再引入一層封裝：一邊是紛繁的實(shí)現(xiàn)細(xì)節(jié)，一邊是干凈利落的接口。這正是引入中等粒度領(lǐng)域服務(wù)的由來(lái)。中等粒度的領(lǐng)域服務(wù)實(shí)質(zhì)上是對(duì)更細(xì)粒度的領(lǐng)域模型對(duì)象之間的流程編制，它的主要作用在于協(xié)調(diào)多個(gè)領(lǐng)域?qū)ο?#xff0c;尤其是多個(gè)細(xì)粒度領(lǐng)域服務(wù)之間的協(xié)作。

還記得《理解領(lǐng)域模型》一節(jié)給出的“訂閱課程”業(yè)務(wù)場(chǎng)景的案例嗎？當(dāng)時(shí)我以可視化的時(shí)序圖方式給出了各個(gè)對(duì)象角色之間的協(xié)作關(guān)系：

顯然，圖中藍(lán)色的應(yīng)用服務(wù) CouseAppService 劃定了一條遠(yuǎn)程服務(wù)與領(lǐng)域?qū)又g的界限，使得遠(yuǎn)程服務(wù)無(wú)需了解課程訂閱領(lǐng)域邏輯的實(shí)現(xiàn)細(xì)節(jié)。課程與期望列表屬于兩個(gè)不同的限界上下文，但它們又都處于同一個(gè)進(jìn)程邊界內(nèi)，因此它們之間的協(xié)作通過(guò)應(yīng)用服務(wù)來(lái)完成。領(lǐng)域服務(wù) SubscriptionValidation 僅僅實(shí)現(xiàn)了對(duì)訂閱的驗(yàn)證功能。它是一個(gè)細(xì)粒度服務(wù)，部分驗(yàn)證的邏輯委派給了 Course 聚合，避免了貧血模型。持久化與郵件通知都屬于基礎(chǔ)設(shè)施服務(wù)，分別由資源庫(kù)和郵件通知南向網(wǎng)關(guān)完成。

領(lǐng)域服務(wù) SubscribeCourseService 并沒(méi)有履行具體的業(yè)務(wù)職責(zé)，它只是將多個(gè)領(lǐng)域?qū)ο蠼M合起來(lái)，進(jìn)行業(yè)務(wù)流程的編制。觀察時(shí)序圖，你會(huì)發(fā)現(xiàn)由該服務(wù)發(fā)出的方法調(diào)用是最多的。這就是所謂的中等粒度領(lǐng)域服務(wù)。它在應(yīng)用層和領(lǐng)域?qū)又g劃定了一條明確的界限，也使得應(yīng)用服務(wù) CouseAppService 得償所愿，成為一個(gè)沒(méi)有領(lǐng)域邏輯的外觀服務(wù)。采用時(shí)序圖的可視化方式，可以觀察應(yīng)用服務(wù)發(fā)起的調(diào)用，即圖中涂為深藍(lán)色的地方。很明顯，應(yīng)用服務(wù)發(fā)起的調(diào)用越少，包含領(lǐng)域邏輯的可能性就越小。