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

1. 引言

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

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

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

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

2. 應用服務

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

是以總結以下：

參考資料

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

推薦連結：你必須知道的.NET Core開發指南

推薦連結：你必須知道的ML.NET開發指南

推薦連結：你必須知道的Office開發指南

推薦連結：你必須知道的IOT開發指南

推薦連結：你必須知道的Azure基礎知識

推薦連結：你必須知道的PowerBI基礎知識

關注我的公衆号『微服務知多少』，我們微信不見不散。

閱罷此文，如果您覺得本文不錯并有所收獲，請【打賞】或【推薦】，也可【評論】留下您的問題或建議與我交流。

你的支援是我不斷創作和分享的不竭動力！

作者：『聖傑』

出處：http://www.cnblogs.com/sheng-jie/

本文版權歸作者和部落格園共有，歡迎轉載，但未經作者同意必須保留此段聲明，且在文章頁面明顯位置給出原文連結，否則保留追究法律責任的權利。