为何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