- 失血模型：模型僅僅包含數據的定義和getter/setter方法，業務邏輯和應用邏輯都放到服務層中。這種類在java中叫POJO。
- 貧血模型：貧血模型中包含了一些業務邏輯，但不包含依賴持久層的業務邏輯。這部分依賴於持久層的業務邏輯將會放到服務層中。可以看出，貧血模型中的領域對象是不依賴於持久層的。
- 充血模型：充血模型中包含了所有的業務邏輯，包括依賴於持久層的業務邏輯。所以，使用充血模型的領域層是依賴於持久層，簡單表示就是 UI層->服務層->領域層<->持久層
- 脹血模型：脹血模型就是把和業務邏輯不想關的其他應用邏輯（如授權、事務等）都放到領域模型中。我感覺脹血模型反而是另外一種的失血模型，因為服務層消失了，領域層干了服務層的事，到頭來還是什么都沒變。
領域模型是否要依賴持久層，因為依賴持久層就意味着單元測試的展開要更加困難（無法脫離框架進行測試，原文的討論中這里專指Hibernate），領域層就更難獨立，將來也更難從應用程序中剝離出來，當然好處是業務邏輯不必混放在不同的層中，使得單一職責性體現的更好。而支持者（充血模型）認為，只要將持久層抽象出來，即可減少測試的困難性，同時適用充血模型畢竟帶來了不少開發上的便利性，除了依賴持久層這一點，擁有更多好處的充血模型仍然值得選擇。我個人則傾向使用充血模型，因為充血模型更加像一個設計完善的系統架構，好在計算機世界里有很多的IOC和DI框架，唯一的缺陷依賴持久層可以通過各種變通的方法繞過，隨着技術的進步，一些缺陷也會被慢慢解決。我的思路是這樣的：先將持久層抽象為接口，然后通過服務層將持久層注入到領域模型中，這樣領域模型僅僅會依賴於持久層的接口。