实战一(下):如何利用基于充血模型的DDD开发一个虚拟钱包系统?

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

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

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

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

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

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

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

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

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

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

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

5. 个人对ddd的理解

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

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

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

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