王争《设计模式之美》学习笔记

钱包业务背景介绍

1. 五个功能：充值、支付、提现、查询余额、交易流水。
2. 业务划分两大块：虚拟钱包、三方支付。文中主要涉及虚拟钱包。
3. 交易流水的两种实现方式：一条记录，出账入账在一起；两条记录，支付与被支付。文中推荐第二种。
4. 交易流水还可以分两种形式：用户看的，包含交易类型；系统看的，只有余额的加减。

基于贫血模型的传统开发模式

1. 基于虚拟钱包，一个典型的 Web 后端项目的三层结构。
2. Controller 中，接口实现比较简单，主要就是调用 Service 的方法。
3. 重点说Service 层，VirtualWalletBo 是一个纯粹的数据结构，只包含数据，不包含任何业务逻辑，业务逻辑集中在 VirtualWalletService 中。

基于充血模型的 DDD 开发模式

1. 也是重点说Service 层，把虚拟钱包 VirtualWallet 类设计成一个充血的Domain 领域模型，并且将原来在 Service 类中的中的部分业务逻辑移动到 VirtualWallet 类中，让Service 类的实现依赖 VirtualWallet 类。
2. 此例子中，领域模型 VirtualWallet 类很单薄，包含的业务逻辑很简单。不过，如果虚拟钱包系统需要支持更复杂的业务逻辑，那充血模型的优势就显现出来了。比如，我们要支持透支一定额度和冻结部分余额的功能。

辩证思考与灵活应用

在基于充血模型的 DDD 开发模式中，哪些功能逻辑会放到 Service 类中？

1. Service 类负责与 Repository 交流。将流程性的代码逻辑与领域模型的业务逻辑解耦，让领域模型更加可复用。
2. Service 类负责跨领域模型的业务聚合功能。
3. Service 类负责一些非功能性及与三方系统交互的工作。

Controller 层和 Repository 层还是贫血模型，是否有必要也进行充血领域建模呢？

1. 没必要做充血建模，即便设计成充血模型，类也非常单薄，看起来也很奇怪。
2. 我们把Entity 传递到 Service 层之后，就会转化成 BO 或Domain 来继续后面的业务逻辑。Entity 的生命周期到此就结束了，所以也并不会被到处任意修改。
3. Controller 层的 VO，主要是作为接口的数据传输承载体，将数据发送给其他系统，理应不包含业务逻辑、只包含数据。