架構設計的"貧血模型"與"充血模型"

    之前就聽別人說過這倆種模型。它們描述的對象是面向對象設計中的實體，構建領域模型(Domain model)時，貧血模型與充血模型給出了倆種不一樣的方案：

貧血模型：是指領域對象裏只有get和set方法，或者包含少許的其它方法，與之有關的業務邏輯都不放在該類中，而是放在其它地方，好比Business logic層。

充血模型：充血模型與之不一樣，不只有get/set方法，還有業務邏輯也在領域模型(Domain model)裏面，Business Logic只是簡單封裝部分業務邏輯以及控制流程。

貧血模型的好處：

    每一個貧血對象職責單一(體如今哪：每一個對象幾乎只有屬性，get/set方法，無業務邏輯)，這樣模塊間、對象間解耦程度很高。

貧血模型的壞處：

    對象狀態和行爲分離(貧血模型中，對象只有屬性，get/set方法，業務邏輯在不在對象類內部)，因此一個完整的業務邏輯描述不能在一個類中完成，而是一組相互協做的類共同完成的。可複用的顆粒度比較小，代碼量膨脹很厲害，很重要的一點是業務邏輯的描述能力較差，一個稍微複雜的業務邏輯，就須要太多類和太多代碼去表達。因爲我公司項目裏使用的就是這種模型，因此對此頗有感觸。

    該模型的缺點是不夠面向對象，領域對象只是保存轉態或者傳遞狀態使用(想象一下項目裏面從web層傳到service層，再傳到dao層)，只有數據沒有行爲的對象不是真正的對象。

充血模型的好處：

    對象自治度很高，表達能力強，適合於複雜的企業業務邏輯實現，可複用程度高。

充血模型的壞處：

    對象自治度高的結果就是不利於大規模團隊分工協做。    

    

參考：

https://www.cnblogs.com/longshiyVip/p/5205451.html

盒馬資深技術專家輝子：領域驅動設計、實踐經驗：https://www.jianshu.com/p/981cd8b5e3b1