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

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與分層架構--秋水逍遙