贫血模型充血模型

在领域驱动设计DDD和 Java 开发中“贫血模型”Anemic Domain Model是一个非常经典但也极具争议的概念。简单来说贫血模型就是对象只包含数据属性和 getter/setter几乎不包含任何业务逻辑。1. 贫血模型的特征在一个典型的贫血模型设计中你会看到大量的“纯数据对象”数据类 (POJO/DTO)里面只有私有字段private fields和与之对应的 getter/setter 方法。业务逻辑类 (Service/Manager)所有的业务逻辑、规则校验、状态变更都写在对应的 Service 层中。代码示例// 贫血的实体类 public class Order { private String status; private double amount; // 只有 getter 和 setter } // 充满逻辑的 Service 类 public class OrderService { public void pay(Order order) { if (PAID.equals(order.getStatus())) { throw new RuntimeException(已支付); } order.setStatus(PAID); // 逻辑操作在外部完成 // 执行支付流程... } }2. 为什么贫血模型这么流行尽管在软件工程理论中它常被当作“反模式”但在实际生产中尤其是 Spring MyBatis 技术栈它非常普遍原因如下符合直觉数据和逻辑分离对于新手来说编写简单的增删改查CRUD非常直接。工具链支持像 MyBatis、Hibernate 等 ORM 框架以及 JSON 序列化库都非常偏好这种只有字段的对象。无状态逻辑这种设计使得业务逻辑层Service通常是无状态的容易进行单元测试和横向扩展。架构简单这种模式非常适合简单的 Web 应用团队沟通成本低代码结构高度标准化。3. 贫血模型的缺陷为什么它被诟病当业务逻辑变得极其复杂时贫血模型会暴露出严重的问题违反面向对象原则面向对象的核心是“封装”。贫血模型将数据暴露在外让外部随意修改这破坏了对象的完整性。逻辑分散屎山预警随着业务增加Service 层会变得极其臃肿。由于业务逻辑分散在各个 Service 中很难搞清楚一个对象到底有哪些合法的状态转移。容易出错任何代码都可以随意调用order.setStatus(PAID)而不需要经过任何校验。对象的状态完全取决于调用者而不是对象自己。“过程式”编程本质上这其实是披着面向对象外壳的过程式编程Procedural Programming它并没有真正发挥 OO 的威力。4. 什么是“充血模型”与之对比与贫血模型相对的是充血模型Rich Domain Model。在充血模型中领域对象不仅包含数据还包含行为业务逻辑。充血模型的改进public class Order { private String status; private double amount; // 逻辑封装在实体内部 public void pay() { if (PAID.equals(this.status)) { throw new RuntimeException(已支付); } this.status PAID; } }在这种模式下Service 层只需要调用order.pay()具体的业务规则由Order对象自己维护。5.什么项目应该考虑使用基于充血模型的DDD开发模式既然基于贫血模型的开发模式已经成为了一种约定俗成的开发习惯那什么样的项目应该考虑使用基于充血模型的DDD开发模式呢刚刚我们讲到基于贫血模型的传统的开发模式比较适合业务比较简单的系统开发。相对应的基于充血模型的DDD开发模式更适合业务复杂的系统开发。比如包含各种利息计算模型、还款模型等复杂业务的金融系统。你可能会有一些疑问这两种开发模式落实到代码层面区别不就是一个将业务逻辑放到Service类中一个将业务逻辑放到Domain领域模型中吗为什么基于贫血模型的传统开发模式就不能应对复杂业务系统的开发而基于充血模型的DDD开发模式就可以呢实际上除了我们能看到的代码层面的区别之外一个业务逻辑放到Service层一个放到领域模型中还有一个非常重要的区别那就是两种不同的开发模式会导致不同的开发流程。基于充血模型的DDD开发模式的开发流程在应对复杂业务系统的开发的时候更加有优势。为什么这么说呢我们先来回忆一下我们平时基于贫血模型的传统的开发模式都是怎么实现一个功能需求的。不夸张地讲我们平时的开发大部分都是SQL驱动SQL-Driven的开发模式。我们接到一个后端接口的开发需求的时候就去看接口需要的数据对应到数据库中需要哪张表或者哪几张表然后思考如何编写SQL语句来获取数据。之后就是定义Entity、BO、VO然后模板式地往对应的Repository、Service、Controller类中添加代码。业务逻辑包裹在一个大的SQL语句中而Service层可以做的事情很少。SQL都是针对特定的业务功能编写的复用性差。当我要开发另一个业务功能的时候只能重新写个满足新需求的SQL语句这就可能导致各种长得差不多、区别很小的SQL语句满天飞。所以在这个过程中很少有人会应用领域模型、OOP的概念也很少有代码复用意识。对于简单业务系统来说这种开发方式问题不大。但对于复杂业务系统的开发来说这样的开发方式会让代码越来越混乱最终导致无法维护。如果我们在项目中应用基于充血模型的DDD的开发模式那对应的开发流程就完全不一样了。在这种开发模式下我们需要事先理清楚所有的业务定义领域模型所包含的属性和方法。领域模型相当于可复用的业务中间层。新功能需求的开发都基于之前定义好的这些领域模型来完成。我们知道越复杂的系统对代码的复用性、易维护性要求就越高我们就越应该花更多的时间和精力在前期设计上。而基于充血模型的DDD开发模式正好需要我们前期做大量的业务调研、领域模型设计所以它更加适合这种复杂系统的开发。6. 如何平衡没有绝对的好坏只有合适的场景。小型项目 / 简单业务CRUD使用贫血模型是完全合理的。引入复杂的领域建模只会增加开发成本导致“过度设计”。复杂业务系统金融、电商核心逻辑必须转向充血模型。如果你的系统逻辑涉及复杂的状态机、多维度的校验使用贫血模型会导致逻辑到处散落最终变成难以维护的“大泥球”。现实的折中很多时候我们可以采用“混合模式”核心实体Entity尽量充血封装核心业务规则比如account.withdraw()。辅助类DTO/VO保持贫血仅用于数据传输和序列化。总结一句话如果你发现你的 Service 类里充满了大量的if-else来判断某个对象的内部状态那么你的代码正在向“贫血陷阱”滑落此时就该考虑把逻辑下沉到实体对象中让它成为一个真正“活的”对象而不是一个冰冷的数据载体。