這次想討論的話題是有關領域驅動設計，和領域驅動設計中使用貧血、失血or充血模型的，在這之前我想討論下當前很多應用的問題，想起這個話題的起因是因為我在InfoQ上面看到這樣一篇文章《Spring Web應用的最大瑕疵》，不得不說，這樣的標題相當吸引人(′·ω·`)，內容和主要觀點大概是這樣的，現在大部分應用Spring框架的Java Web應用都相當關注單一職責原則和關注分離原則，但是在此之上卻誕生了一些不太好的反模式和設計原則，比如：
- 領域模型物件只是用來存盤應用的資料（領域模型使用了貧血模型這種反模式），
- 業務邏輯位于服務層中，管理域物件的資料，
- 在服務層中，應用的每個物體對應一個服務類，
這類設計原則的應用非常廣泛，我現在所在的Java Web專案就是使用這樣的設計原則進行架構設計的，基本都是常見的三層或多層架構，他們大概是什么樣的呢？
- Web層（俗稱展現層吧，Presentation Layer)：接收用戶輸入，將資料傳至服務層；
- 服務層(Service Layer，可以叫Business Logic Layer)：事務邊界，處理業務邏輯、權限管理與授權，并與存盤層通信；
- 存盤層（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是通用的嘛，
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/102256.html
標籤：其他
上一篇：Envi 5.1 大氣校正模塊（Landsat8遙感影像處理）
下一篇：想問個關于ps的問題