爲什麼DDD認爲JavaBean是缺血模型

JavaBean被稱爲anemic domain model的緣由是JavaBean或者POJO徹底淪爲了properties bag（能夠類比到C/C++裏的struct）。

DDD的爭論認爲一個POJO而後加上一堆setter和getter根本稱不上爲一個Object（對象），對象是真實世界業務對象的反應。

回想剛學Java的的時候，經典的Java書籍裏是否是會讓你寫一個Cat，Dog類，而後繼承Animal接口，他們有eat、bark、shit、pee等行爲。

對象的意義在於封裝並提供行爲，而POJO的setter、getter破壞了封裝。
並且更糟糕的是，只提供setter和getter的POJO在面對真實業務對象的時候就會顯得弊端重重。

仍是拿Cat作例子，好比你餵它食物，貓會的happy指數會提升，飢餓感會降低，對主人的忠誠度也會提升，在DDD裏，咱們只要這樣寫就OK了：cat.feed(food)，若是是POJO的話就會變成：

cat.setHappiness(..);
cat.setLoyalty(..);
cat.setHunger(..)

並且POJO是違反SRP原則的（若是要修改一個類，那麼指應該是它的職責發生變化，而不該該是其餘）。

若是項目經理某天告訴你，貓被餵食後還要增長毛色的光澤度，若是是DDD設計的，咱們只須要修改Cat.feed的實現就好了。

而若是是POJO的話，那麼咱們要在全部原來cat.setHappiness(..), cat.setLoyalty(..), cat.setHunger(..)的地方添加一個cat.set毛色光澤度(..)。

你可能會爭論，我能夠把feed的業務邏輯寫在Service裏嘛，可是這就違反了OOD（對象是數據的封裝和行爲的組合），

並且由於你已經暴露了setter和getter，那麼程序員一定會繞過你的Service，這樣對系統來講也就增長了混亂。

能夠看Martin Fowler的這篇文章 AnemicDomainModel