为什么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