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

1. 引言

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

• 應用層（Application）：負責展現層與領域層之間的協調，協調業務對象來執行特定的應用程式任務。它不包含業務邏輯。
• 領域層（Domain）：負責表達業務概念，業務狀態信息以及業務規則，是業務軟體的核心。

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

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

2. 應用服務

應用服務是用來表達用例和用戶故事（User Story)的主要手段。

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

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

應用層作為展現層與領域層的橋梁。展現層使用VO（視圖模型）進行界面展示，與應用層通過DTO（數據傳輸對象）進行數據交互，從而達到展現層與DO（領域對象）解耦的目的。

3.領域服務

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

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

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

1. 什麼時候使用領域服務？
2. 領域服務無狀態怎麼理解？

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

上面也說了，領域對象是具有狀態和行為的。那就是說我們也可以在實體或值對象來處理業務邏輯。那我們該如何取捨呢？
一般來說，在下麵的幾種情況下，我們可以使用領域服務：

• 執行一個顯著的業務操作過程
• 對領域對象進行轉換
• 以多個領域對象為輸入，返回一個值對象。

4. 案例分析

我們拿經典的轉賬問題來分析一下：
而針對轉賬這一操作，它的業務用例應該是這樣的：

1. 檢查賬號餘額是否足夠
2. 檢查目標賬戶賬號是否合法
3. 轉賬
4. 簡訊通知轉賬雙方

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

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

5.總結

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

所以總結以下：

1. 服務是行為的抽象。
2. 應用服務通過委托領域對象和領域服務來表達用例和用戶故事。
3. 領域對象（實體和值對象）負責單一操作。
4. 領域服務用於協調多個領域對象共同完成某個業務操作。
5. 應用服務不處理業務邏輯，領域服務處理業務邏輯。

參考資料
DDD與分層架構--秋水逍遙