实战一（下）：如何利用基于充血模型的DDD开发一个虚拟钱包系统？

1. 什么是贫血模型？什么是充血模型？

贫血模型：只包含数据，不包含业务逻辑的类

充血模型：既包含数据，也包含业务逻辑的类

2. 为什么说基于贫血模型的传统开发模式违反 OOP?

这种贫血模型将数据与操作分离，破坏了面向对象的封装特性，是一种典型的面向过程的编程风格。

个人感觉，就是封装对象不彻底，贫血模型要么只包含数据，要么只包含业务逻辑，使对象功能不够饱满。

3. 基于贫血模型的传统开发模式既然违反 OOP，那又为什么如此流行？

第一点原因是，大部分情况下，我们开发的系统业务可能都比较简单，简单到就是基于 SQL 的 CRUD 操作，所以，我们根本不需要动脑子精心设计充血模型，贫血模型就足以应付这种简单业务的开发工作。

第二点原因是，充血模型的设计要比贫血模型更加有难度。

4. 什么情况下我们应该考虑使用基于充血模型的 DDD 开发模式？

基于充血模型的 DDD 开发模式，更适合业务复杂的系统开发。比如，包含各种利息计算模型、还款模型等复杂业务的金融系统。

5. 个人对ddd的理解

把传统的service功能逻辑，搬一部分到BO,那哪些需要搬呢，我觉得这就要对业务的深刻理解，抽象每个业务的共性。

比如，库存功能，在库存业务里，可能会有供应商到集团，集团到分公司，分公司到园区，每个角色他们都有自己的库存，对应的，库存操作类型就会有供应商出库，供应商入库，集团出库，集团出库等等。

按照传统贫血模型，我们会这所有的库存操作分别写一个service方法来操作库存，这样的缺点就是每个方法都是特定的实现，代码冗余

而按照充血模型，对于库存这个类来说，库存操作不过就是加加减减，他只要实现库存的加减就可以，并不关心是什么操作类型，这是使用库存类该关心的事，所以这一部分可以写在库存BO中，这样的优点是抽取了业务核心，减少了代码冗余