轉載：本文轉載自：https://www.cnblogs.com/sheng-jie/p/7097129.html 作者：『圣杰』 出處：http://www.cnblogs.com/sheng-jie/ 本文著作權歸作者和博客園共有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文鏈接，否則保留追究法律責任的權利，
1. 引言
單從字面理解，不管是領域服務還是應用服務，都是服務，而什么是服務？從SOA到微服務，它們所描述的服務都是一個寬泛的概念，我們可以理解為服務是行為的抽象，從前綴來看，根據DDD的經典分層架構，它們又隸屬于不同的層，應用服務屬于應用層，領域服務屬于領域層，
- 應用層（Application）：負責展現層與領域層之間的協調，協調業務物件來執行特定的應用程式任務，它不包含業務邏輯，
- 領域層（Domain）：負責表達業務概念，業務狀態資訊以及業務規則，是業務軟體的核心，
所以綜合來看應用服務是用來表述應用行為，而領域服務用來表述領域行為，
那怎么理解應用行為和領域行為呢，應用行為描述了一個具體操作從開始到結束的每一個環節，而領域行為是對應用行為的細化，用來處理具體的某一個環節，比如，我們手機購物，從購物車結算這一場景來舉例，這就是一個應用行為，而這個應用行為又主要包括金額計算、支付、生成訂單，這些子環節就可以理解為一個領域行為，
我們就不咬文嚼字了，下面我們就一一展開，
2. 應用服務
應用服務是用來表達用例和用戶故事（User Story)的主要手段，
應用層通過應用服務介面來暴露系統的全部功能，在應用服務的實作中，它負責編排和轉發，它將要實作的功能委托給一個或多個領域物件來實作，它本身只負責處理業務用例的執行順序以及結果的拼裝，通過這樣一種方式，它隱藏了領域層的復雜性及其內部實作機制，
應用層相對來說是較“薄”的一層，除了定義應用服務之外，在該層我們可以進行安全認證，權限校驗，持久化事務控制，或者向其他系統發生基于事件的訊息通知，另外還可以用于創建郵件以發送給客戶等，
應用層作為展現層與領域層的橋梁，展現層使用VO（視圖模型）進行界面展示，與應用層通過DTO（資料傳輸物件）進行資料互動，從而達到展現層與DO（領域物件）解耦的目的，
3.領域服務
領域層就是較“胖”的一層，因為它實作了全部業務邏輯并且通過各種校驗手段保證業務正確性，而什么是業務邏輯呢？業務流程、業務策略、業務規則、完整性約束等，
當領域中的某個操作程序或轉換程序不是物體或值物件的職責時，我們便應該將該操作放在一個單獨的介面中，即領域服務，請確保該服務和通用語言時一致的；并且保證它是無狀態的，
根據這句話我們有幾個問題需要理清：
- 什么時候使用領域服務？
- 領域服務無狀態怎么理解？
領域服務是用來協調領域物件完成某個操作，用來處理業務邏輯的，它本身是一個行為，所以是無狀態的，狀態由領域物件（具有狀態和行為）保存，
上面也說了，領域物件是具有狀態和行為的，那就是說我們也可以在物體或值物件來處理業務邏輯，那我們該如何取舍呢？
一般來說，在下面的幾種情況下，我們可以使用領域服務：
- 執行一個顯著的業務操作程序
- 對領域物件進行轉換
- 以多個領域物件為輸入，回傳一個值物件，
4. 案例分析
我們拿經典的轉賬問題來分析一下：
而針對轉賬這一操作，它的業務用例應該是這樣的：
- 檢查賬號余額是否足夠
- 檢查目標賬戶賬號是否合法
- 轉賬
- 短信通知轉賬雙方
其中1,2步是轉賬的合法性校驗屬于轉賬業務的一部分，所以，1,2,3均應該放到領域層通過領域服務來實作，短信通知，它并不是是轉賬的核心業務，因為這根據具體情況而定，比如只有客戶訂閱了賬號變動通知我才發短信，所以將第4步歸類到應用服務中去實作，就確保了領域服務的純粹性，
而至于持久化的問題，我們可以這樣想，領域邏輯應該只關心業務邏輯，才能保證領域邏輯的可重用性，將持久化放到應用層，我們就會有更多的選擇性，
5.總結
當應用服務中的邏輯趨于復雜時，我們就要小心領域邏輯泄露到應用服務中去，而在使用領域服務時，我們又要避免過度使用，因為會導致貧血領域模型，畢竟有些單一的操作更適合放到領域物件（物體和值物件）中去，
所以總結以下：
- 服務是行為的抽象，
- 應用服務通過委托領域物件和領域服務來表達用例和用戶故事，
- 領域物件（物體和值物件）負責單一操作，
- 領域服務用于協調多個領域物件共同完成某個業務操作，
- 應用服務不處理業務邏輯，領域服務處理業務邏輯，
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/228917.html
標籤：領域驅動設計