王争《设计模式之美》学习笔记
钱包业务背景介绍
五个功能：充值、支付、提现、查询余额、交易流水。业务划分两大块：虚拟钱包、三方支付。文中主要涉及虚拟钱包。交易流水的两种实现方式：一条记录，出账入账在一起；两条记录，支付与被支付。文中推荐第二种。交易流水还可以分两种形式：用户看的，包含交易类型；系统看的，只有余额的加减。
基于贫血模型的传统开发模式
基于虚拟钱包，一个典型的 Web 后端项目的三层结构。Controller 中，接口实现比较简单，主要就是调用 Service 的方法。重点说Service 层，VirtualWalletBo 是一个纯粹的数据结构，只包含数据，不包含任何业务逻辑，业务逻辑集中在 VirtualWalletService 中。
基于充血模型的 DDD 开发模式
也是重点说Service 层，把虚拟钱包 VirtualWallet 类设计成一个充血的Domain 领域模型，并且将原来在 Service 类中的中的部分业务逻辑移动到 VirtualWallet 类中，让Service 类的实现依赖 VirtualWallet 类。此例子中，领域模型 VirtualWallet 类很单薄，包含的业务逻辑很简单。不过，如果虚拟钱包系统需要支持更复杂的业务逻辑，那充血模型的优势就显现出来了。比如，我们要支持透支一定额度和冻结部分余额的功能。
辩证思考与灵活应用
在基于充血模型的 DDD 开发模式中，哪些功能逻辑会放到 Service 类中？
Service 类负责与 Repository 交流。将流程性的代码逻辑与领域模型的业务逻辑解耦，让领域模型更加可复用。Service 类负责跨领域模型的业务聚合功能。Service 类负责一些非功能性及与三方系统交互的工作。
Controller 层和 Repository 层还是贫血模型，是否有必要也进行充血领域建模呢？
没必要做充血建模，即便设计成充血模型，类也非常单薄，看起来也很奇怪。我们把Entity 传递到 Service 层之后，就会转化成 BO 或Domain 来继续后面的业务逻辑。Entity 的生命周期到此就结束了，所以也并不会被到处任意修改。Controller 层的 VO，主要是作为接口的数据传输承载体，将数据发送给其他系统，理应不包含业务逻辑、只包含数据。
