原文發布于2013年12月6日

　　工作地點轉換成家中后，最近都沒什么心情寫博客了（好吧我承認是我懶）。之前的幾篇都比較水，今天來個（對于我來說）難度略高的內容吧。

　　這次想討論的話題是有關領域驅動設計，和領域驅動設計中使用貧血、失血or充血模型的。在這之前我想討論下當前很多應用的問題，想起這個話題的起因是因為我在InfoQ上面看到這樣一篇文章《Spring Web應用的最大瑕疵》，不得不說，這樣的標題相當吸引人(′·ω·`)。內容和主要觀點大概是這樣的，現在大部分應用Spring框架的Java Web應用都相當關注單一職責原則和關注分離原則，但是在此之上卻誕生了一些不太好的反模式和設計原則，比如：

• 領域模型對象只是用來存儲應用的數據（領域模型使用了貧血模型這種反模式）。
• 業務邏輯位于服務層中，管理域對象的數據。
• 在服務層中，應用的每個實體對應一個服務類。

　　這類設計原則的應用非常廣泛，我現在所在的Java Web項目就是使用這樣的設計原則進行架構設計的，基本都是常見的三層或多層架構，他們大概是什么樣的呢？

1. Web層（俗稱展現層吧，Presentation Layer)：接收用戶輸入，將數據傳至服務層；
2. 服務層(Service Layer，可以叫Business Logic Layer)：事務邊界，處理業務邏輯、權限管理與授權，并與存儲層通信；
3. 存儲層（Data access layer）：與數據庫進行通信，對數據進行持久化。

　　但是發現什么沒有？問題出在了服務層，他承受了太多的職責，像事務管理、業務邏輯、權限檢查等等，這違反了單一職責原則和關注分離原則，并且產生了大量的依賴和循環依賴。當業務復雜度上升時，服務層所包含的代碼將會非常龐大和復雜，直接導致了測試成本的上升。

　　我這里正好有個例子，在現在的項目中，負責處理保險業務單的核心類中，包含了4000多行代碼，它與數據庫中某一關鍵表相關聯，引用（注入）了十幾個DAO。在數十個各類方法中，可以處理保單、再保、理賠等等各種不同的業務，同時它還深度依賴于Hibernate，不但使用了ORM方法處理數據，甚至還直接用了HQL來獲取數據。因為有眾多其他服務類與他進行循環引用，項目后期這個龐然大物已經沒有人敢輕易改動了，因為誰也不知道他到底都能做什么，重構更是不可能的事。

　　說了些服務層的壞話，那應該怎么改進呢？

• 首先，我們需要將業務邏輯從服務層移動到領域模型中，這樣的好處是，服務層可以只負責應用邏輯（如數據有效性驗證、授權檢查、開始結束事務等），領域模型可以專門負責其相關的業務邏輯。還是以之前的保單系統來距離，架構設計時完全可以針對保單、再保、理賠等多個領域模型進行建模，相關的業務可以分別放到不同的領域模型中，一些很有可能重復的業務代碼都會被集中到一處，從而降低了復制-粘貼的可能性。
• 其次，將服務類變得更小，使之只負責單一的職責。文章中有個例子，例如用戶賬戶的CRUD和其他操作，就可以將其放到兩個不同的服務類中，一個負責賬戶的CRUD操作，另外一個負責與用戶賬戶相關的其他操作。

　　這樣就能使服務類變得小巧、松散、可測試了，同時還能降低其他人理解與重用的成本。

　　接下來的問題就是，在實際的項目中，怎樣實踐這些設計原則呢？

　　這里有一篇《領域驅動設計和開發實踐》非常值得一看，他所推崇的分層結構和上文所述類似，甚至提出了一些更細節的規則：

• 服務層需要包含應用邏輯、用戶會話的管理，但不能包含領域邏輯、業務邏輯和數據訪問邏輯；
• 領域層（領域對象）應該包含業務邏輯，可以處理與業務相關的會話狀態。但作為商業應用的核心，應該具有良好的可移植性，不能對特定框架（如Struts、Hibernate、EJB等）產生依賴。

　　說到這里，終于到了討論的正題——貧血、失血和充血模型。什么是貧血失血充血模型呢？簡單來說

• 失血模型：模型僅僅包含數據的定義和getter/setter方法，業務邏輯和應用邏輯都放到服務層中。這種類在Java中叫POJO，在.NET中叫POCO。
• 貧血模型：貧血模型中包含了一些業務邏輯，但不包含依賴持久層的業務邏輯。這部分依賴于持久層的業務邏輯將會放到服務層中。可以看出，貧血模型中的領域對象是不依賴于持久層的。
• 充血模型：充血模型中包含了所有的業務邏輯，包括依賴于持久層的業務邏輯。所以，使用充血模型的領域層是依賴于持久層，簡單表示就是 UI層->服務層->領域層<->持久層。
• 脹血模型：脹血模型就是把和業務邏輯不想關的其他應用邏輯（如授權、事務等）都放到領域模型中。我感覺脹血模型反而是另外一種的失血模型，因為服務層消失了，領域層干了服務層的事，到頭來還是什么都沒變。

　　可以看出來，失血模型和脹血模型都是不可取的，現在的問題是，貧血模型和充血模型哪個更加好一些。很久很久以前，人們針對這個問題進行了曠日持久的爭論，最后仍然沒有什么結果。這里有一些帖子可供回味：

　　貧血，充血模型的解釋以及一些經驗

　　總結一下最近關于domain object以及相關的討論

　　雙方爭論的焦點主要在我上面加粗的兩句話上，就是領域模型是否要依賴持久層，因為依賴持久層就意味著單元測試的展開要更加困難（無法脫離框架進行測試，原文的討論中這里專指Hibernate），領域層就更難獨立，將來也更難從應用程序中剝離出來，當然好處是業務邏輯不必混放在不同的層中，使得單一職責性體現的更好。而支持者（充血模型）認為，只要將持久層抽象出來，即可減少測試的困難性，同時適用充血模型畢竟帶來了不少開發上的便利性，除了依賴持久層這一點，擁有更多好處的充血模型仍然值得選擇。最后，誰也沒能說服誰，關于貧血模型和充血模型的選擇，更多的要靠具體的業務場景來決定，并不能說哪一種更比哪一種好。設計模式這種東西不是向來都沒有什么定論么。

　　我個人則傾向使用充血模型，因為充血模型更加像一個設計完善的系統架構，好在計算機世界里有很多的IOC和DI框架，唯一的缺陷依賴持久層可以通過各種變通的方法繞過，隨著技術的進步，一些缺陷也會被慢慢解決。我的思路是這樣的：先將持久層抽象為接口，然后通過服務層將持久層注入到領域模型中，這樣領域模型僅僅會依賴于持久層的接口。而這個接口，可以利用現有框架的技術進行抽象。舉例來說，Java版Hibernate我了解不多，就以.NET的Entity Framework來說吧：

　　現在有這么一個DbContext，大家都懂得，DbContext和DbSet是非常不好Mock的兩個類（我就是嫌麻煩而已，高手請無視），里面有兩個表，一個叫Animes另一個叫Users

　　怎樣設計接口才能使它既容易使用又可以方便測試呢？直接提取一個接口？DbSet不容易Mock的問題還是沒有解決吧。

　　好在我們有LINQ和IQueryable<T>，隨便改造一下，接口就變成了這樣：

　　　請注意Query<T>()方法，這個方法返回一個IQueryable<T>的對象，而實現了IQueryable的對象是支持LINQ操作的，也就是說，我們可以仍然可以將搜索的Expression交給真正的DbContext來做，而這個DbContext只需要簡單一句話：

　　查詢時從 from a in db.Anime.AsQueryable() 改成 from a in db.Query<Anime>()，一切都解決了。當你在單元測試中想要返回一個假的數據源的時候，直接讓FakeDb.Query<T>()方法返回一個擁有假數據的List<T>.AsQueryable()就可以了。這樣就實現了領域層和持久層的解耦，畢竟IQueryable是通用的嘛。