领域模型之贫血模型与充血模型

文章目录

• 领域模型之贫血模型与充血模型
• • 一、什么是领域驱动设计?
  • 二、贫血模型
  • 三、充血模型
  • 四、为什么基于贫血模型的传统开发模式如此受欢迎?
  • 五、代码实战
  • 六、总结

一、什么是领域驱动设计?

领域驱动设计，即 DDD，主要是用来指导如何解耦业务系统，划分业务模块，定义业务领域模型及其交互。领域驱动设计这个概念并不新颖，早在2004年就被提出了，到现在已经有十几年的历史了。不过，它被大众熟知，还是基于另一个概念的兴起，那就是微服务。
我们知道，除了监控、调用链追踪、API网关等服务治理系统的开发之外，微服务还有另外一个更加重要的工作，那就是针对公司的业务，合理地做微服务拆分。而领域驱动设计恰好就是用来指导划分服务的。所以，微服务加速了领域驱动设计的盛行。

二、贫血模型

简单来说，贫血模型表现在：Entity或者为BO是一个纯粹的数据结构，只包含数据，不包含任何业务逻辑（或者是有一些原子服务，如获得关联model的id，以此与失血模型区分开），业务逻辑全部集中再Service中。可以理解为Service层数据与业务逻辑被分割到BO和Service两个类中。
像这样只包含数据而不包含逻辑的类被叫做贫血模型，贫血模型是面向过程的。

三、充血模型

充血模型与贫血模型正好相反，数据与业务被封装到同一类中，充血模型满足面向对象的封装特性，因此是面向对象编程风格的。

四、为什么基于贫血模型的传统开发模式如此受欢迎?

前面我们讲过，基于贫血模型的传统开发模式，将数据与业务逻辑分离，违反了OOP的封装特性，实际上是一种面向过程的编程风格。但是，现在几乎所有的Web项目，都是基于这种贫血模型的开发模式，甚至连Java Spring 框架的官方demo，都是按照这种开发模式来编写的。
但是面向过程编程风格有种种弊端，比如，数据和操作分离之后，数据本身的操作就不受限制了。任何代码都可以随意修改数据。既然基于贫血模型的这种传统开发模式是面向过程编程风格的，那它又为什么会被广大程序员所接受呢?关于这个问题，我总结了下面三点原因。

1. 当下业务逻辑都较为简单，使用充血模型意义不大。
2. 贫血模型比充血模型简单，更容易编写。充血模型需要提前分析好需求，定义好暴露出哪些操作和相关业务逻辑。而贫血模型定义好实体类后，有什么功能直接写在Service中即可。
3. 思维固化，积重难返。

五、代码实战

这里参考了设计模式之美的实战案例，我觉得很有意义。我放一下原文和我整理的代码。
《设计模式之美》实战一（下）：如何利用基于充血模型的DDD开发一个虚拟钱包系统？
贫血模型与充血模型——虚拟钱包系统Code

六、总结

充血模型开发方式与基于贫血模型的传统开发模式的区别主要在Service 层。在基于贫血模型的传统开发模式中，Service层包含Service类和BO类两部分，BO是贫血模型，只包含数据，不包含具体的业务逻辑。业务逻辑集中在Service类中。在基于充血模型的DDD开发模式中，Service层包含Service类和Domain类两部分。Domain 就相当于贫血模型中的BO。不过，Domain与BO的区别在于它是基于充血模型开发的，既包含数据，也包含业务逻辑。而Service类变得非常单薄。总结一下的话就是，基于贫血模型的传统的开发模式，重Service轻BO;基于充血模型的DDD开发模式，轻Service重 Domain。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！