优点

简单

• 对于只有少量业务逻辑的应用来说，使用起来非常自然
• 开发迅速，易于理解
• 注意：也不能完全排斥这种方式

缺点

无法良好的应对复杂逻辑

• 比如收入确认规则发生变化，例如在4月1号之前签订的合同要使用某规则…
• 和欧洲签订的合同使用另外一个规则…

充血模型

面向对象设计的本质：“一个对象是拥有状态和行为的”，比如一个人：

• 他眼睛什么样鼻子什么样这就是状态
• 人可以去打游戏或是写程序，这就是行为
• 为什么要有一个“人Manager”这样的东西存在去帮人“打游戏”呢？

举个简单的J2EE案例，设计一个与用户（User）相关功能。

传统的设计一般是：

类：User+UserManager

保存用户调用：userManager.save(User user)

充血的设计则可能会是：

类：User

保存用户调用：user.save()

User有一个行为是：保存它自己

其实它们没有什么特别适用的方向，个人更倾向于总是使用充血模型，因为OOP总是比面向过程编程要有更丰富的语义、更合理的组织、更强的可维护性—当然也更难掌握。因此实际工程场景中，是否使用，如何使用还依赖于设计者以及团队充血模型设计的理解和把握，因为现在绝大多数J2EE开发者都受贫血模型影响非常深。另外，实际工程场景中使用充血模型还会碰到很多很多细节问题，其中最大的难关就是“如何设计充血模型”或者说“如何从复杂的业务中分离出恰到好处且包含语义的逻辑放到VO的行为中”。

如果一个对象包含其他对象，那就将职责继续委托下去，由具体的 POJO 执行业务逻辑，将策略模式更加细粒度，而不是写 ifelse。

参考

《领域驱动设计》

https://www.zhihu.com/question/20360521/answer/14891150

https://www.martinfowler.com/bliki/AnemicDomainModel.html