设计模式之美笔记 —— 贫血模型，充血模型

设计模式之美 - 11

贫血模型：只包含数据，不包含业务逻辑的类，就叫做贫血模型。这种模型将数据与操作分开，破坏了面向对象的封装特性，是一种典型的面向过程的编程风格。日常应用的oc2中的DO及其相对应的service层，数据和操作分开的方式。

充血模型：数据和对应的业务逻辑被封装在了一个类中。满足了封装特性。基于充血模型的DDD（领域驱动设计 — Domain Driven Design，简称 DDD）开发模式越来越流行了。

领域驱动设计：主要是用来指导如何解耦业务系统，划分业务模块，定义业务领域的模型及其交互。做好领域驱动设计的关键是，看你对自己所做的业务的熟悉程度，而并不是对于领域驱动设计这个概念本身的掌握程度。

总结一下的话就是，基于贫血模型的传统的开发模式，重 Service 轻 BO；基于充血模型的 DDD 开发模式，轻 Service 重 Domain。Domain 就相当于贫血模型中的 BO。不过，Domain 与 BO 的区别在于它是基于充血模型开发的，既包含数据，也包含业务逻辑。

 

设计模式之美 - 12 

开发一个虚拟钱包的设计 以及 分别用贫血模式 和 充血模式的不同开发方式。

• 最底层的虚拟钱包，为了保证其中功能的通用行，不要耦合相关的业务逻辑（提现，充值，等）
• 再设计表的时候，需要考虑，该设计模式对于数据的一致性（数据方面，业务方面）的问题。

 

第二个要讨论问题是：在基于充血模型的 DDD 开发模式中，尽管 Service 层被改造成了充血模型，但是 Controller 层和 Repository 层还是贫血模型，是否有必要也进行充血领域建模呢？

答案是没有必要。Controller 层主要负责接口的暴露，Repository 层主要负责与数据库打交道，这两层包含的业务逻辑并不多，前面我们也提到了，如果业务逻辑比较简单，就没必要做充血建模，即便设计成充血模型，类也非常单薄，看起来也很奇怪。