DDD理論學習系列（8）應用服務領域服務

ddd理論學習系列——案例及目錄

單從字面理解，不管是領域服務還是應用服務，都是服務。而什麼是服務？從soa到微服務，它們所描述的服務都是乙個寬泛的概念，我們可以理解為服務是行為的抽象。從字首來看，根據ddd的經典分層架構，它們又隸屬於不同的層，應用服務屬於應用層，領域服務屬於領域層。

領域層（domain）：負責表達業務概念，業務狀態資訊以及業務規則，是業務軟體的核心。

所以綜合來看應用服務是用來表述應用行為，而領域服務用來表述領域行為。

那怎麼理解應用行為和領域行為呢，應用行為描述了乙個具體操作從開始到結束的每乙個環節，而領域行為是對應用行為的細化，用來處理具體的某乙個環節。比如，我們手機購物，從購物車結算這一場景來舉例，這就是乙個應用行為。而這個應用行為又主要包括金額計算、支付、生成訂單，這些子環節就可以理解為乙個領域行為。

我們就不咬文嚼字了，下面我們就一一展開。

應用服務是用來表達用例和使用者故事（user story)的主要手段。

應用層通過應用服務介面來暴露系統的全部功能。在應用服務的實現中，它負責編排和**，它將要實現的功能委託給乙個或多個領域物件來實現，它本身只負責處理業務用例的執行順序以及結果的拼裝。通過這樣一種方式，它隱藏了領域層的複雜性及其內部實現機制。

應用層相對來說是較「薄」的一層，除了定義應用服務之外，在該層我們可以進行安全認證，許可權校驗，持久化事務控制，或者向其他系統發生基於事件的訊息通知，另外還可以用於建立郵件以傳送給客戶等。

應用層作為展現層與領域層的橋梁。展現層使用vo（檢視模型）進行介面展示，與應用層通過dto（資料傳輸物件）進行資料互動，從而達到展現層與do（領域物件）解耦的目的。

領域層就是較「胖」的一層，因為它實現了全部業務邏輯並且通過各種校驗手段保證業務正確性。而什麼是業務邏輯呢？業務流程、業務策略、業務規則、完整性約束等。

當領域中的某個操作過程或轉換過程不是實體或值物件的職責時，我們便應該將該操作放在乙個單獨的介面中，即領域服務。請確保該服務和通用語言時一致的；並且保證它是無狀態的。

根據這句話我們有幾個問題需要理清：

什麼時候使用領域服務？

領域服務無狀態怎麼理解？

領域服務是用來協調領域物件完成某個操作，用來處理業務邏輯的，它本身是乙個行為，所以是無狀態的。狀態由領域物件（具有狀態和行為）儲存。

上面也說了，領域物件是具有狀態和行為的。那就是說我們也可以在實體或值物件來處理業務邏輯。那我們該如何取捨呢？

一般來說，在下面的幾種情況下，我們可以使用領域服務：

我們拿經典的轉賬問題來分析一下：

而針對轉賬這一操作，它的業務用例應該是這樣的：

檢查賬號餘額是否足夠

檢查目標賬戶賬號是否合法

轉賬簡訊通知轉賬雙方

其中1,2步是轉賬的合法性校驗屬於轉賬業務的一部分，所以，1,2,3均應該放到領域層通過領域服務來實現。簡訊通知，它並不是是轉賬的核心業務，因為這根據具體情況而定，比如只有客戶訂閱了賬號變動通知我才發簡訊。所以將第4步歸類到應用服務中去實現，就確保了領域服務的純粹性。

而至於持久化的問題，我們可以這樣想，領域邏輯應該只關心業務邏輯，才能保證領域邏輯的可重用性。將持久化放到應用層，我們就會有更多的選擇性。

當應用服務中的邏輯趨於複雜時，我們就要小心領域邏輯洩露到應用服務中去。而在使用領域服務時，我們又要避免過度使用，因為會導致貧血領域模型。畢竟有些單一的操作更適合放到領域物件（實體和值物件）中去。

所以總結以下：

服務是行為的抽象。

應用服務通過委託領域物件和領域服務來表達用例和使用者故事。

領域物件（實體和值物件）負責單一操作。

領域服務用於協調多個領域物件共同完成某個業務操作。

應用服務不處理業務邏輯，領域服務處理業務邏輯。

參考資料

ddd與分層架構--秋水逍遙

DDD理論學習系列（8） 應用服務 領域服務