http://www.jdon.com/45857
Spring的web應用程序:
1. Web層負責處理用戶輸入，并返回正確的響應返回給用戶。 web層與服務層通信。
2.服務層作為一個事務邊界。它也負責授權和包含我們的應用程序的業務邏輯。服務層管理的域模型對象，并與其他服務和存儲庫層進行通信。
3.存儲庫/數據訪問層負責與所使用的數據的存儲進行通信。
服務層有兩個主要問題：
1.在服務層發現業務邏輯
業務邏輯被分散在各個服務層。如果我們需要檢查一個業務規則是如何實現的，我們必須先找到它。這可能并不容易。此外，如果相同的業務規則需要在多個服務類，問題是，規則需要從一個服務到另一個簡單地復制。這將導致維護的噩夢。
2.每個領域模型一個服務
這完全違反了單一職責原則，它被定義為如下：單一職責原則指出，每一個類都應該有一個責任，責任應該由類完全封裝。其所有的服務應該狹義與責任相一致。(不應將原屬于領域模型的行為方法等劃放在服務中實現，對象不但有屬性還有行為)
服務類有很多依賴，以及大量的循環依賴。更像網絡緊密耦合和單片服務。這使得很難理解，維護和重用。這聽起來有點苛刻，但一個Spring的web應用的服務層往往是最容易出問題的部分。幸運的是，所有的希望都不會丟失。
1. 我們必須將我們的應用程序的業務邏輯從服務層遷移到領域模型類中。
舉個例子：假設我是一個服務類，你是一個域模型對象。如果我讓你從屋頂上跳下來，你會喜歡我這樣的決定嗎？(跳下來會摔傷，自己沒有腦子或被洗腦，變成僵尸，只聽從執行，不思考自己的安全，這就是貧血模型的問題)
將業務邏輯從服務層遷移到域模型類有下面三個優勢：
(1)我們的代碼將以邏輯方式切割，服務層只要關注應用邏輯，而我們的領域模型關注業務邏輯。
(2)業務邏輯只存在一個地方，容易發現修改。
(3)服務層的源代碼是清潔的，不包含任何復制粘貼代碼
2. 將每個實體服務切割為單一目標的更小的服務。
比如，有一個單一服務類，提供對人員和用戶賬戶的CRUD操作，我們應該將它分為兩個獨立的服務類：
第一個是對人員的提供CRUD操作
第二個是提供與用戶賬戶相關的操作。
好處：每個服務類中有一個邏輯組職責。每個服務類的依賴較少，這意味著他們不再是緊耦合的源頭。他們是較小的和松耦合的組件。服務類更容易理解，維護和重用。
