什么是充血模型和贫血模型？

**充血模型**和**贫血模型**是领域驱动设计（DDD）中常用的设计模式，主要区别在于业务逻辑在代码中的组织方式。 ### 1. 充血模型（Rich Model） 充血模型指的是实体对象既包含数据属性，又包含与该对象相关的业务逻辑或行为。在这种模型中，业务逻辑直接绑定在实体类中，实体类自身可以处理相关业务逻辑，形成“充血”的对象。 #### 充血模型的特点 - **业务逻辑内聚**：业务逻辑直接在实体类中实现。 - **对象行为丰富**：实体对象不仅有属性，还可以执行业务操作。 - **符合面向对象的思想**：对象即包含数据又包含操作，更贴合实际业务场景。 #### 电商场景中的充血模型例子 在电商系统中，“订单（Order）”实体可以被设计为充血模型。该模型下，订单不仅有数据属性（如订单号、订单状态、商品列表等），而且包含订单的操作方法： ```java public class Order { private String orderId; private List<Item> items; private OrderStatus status; // 构造方法和属性的getter/setter省略 // 业务方法 public void addItem(Item item) { items.add(item); } public void removeItem(Item item) { items.remove(item); } public void pay(Payment payment) { if (this.status == OrderStatus.PENDING) { // 处理支付逻辑 this.status = OrderStatus.PAID; } } public void cancel() { if (this.status == OrderStatus.PENDING) { // 取消订单逻辑 this.status = OrderStatus.CANCELLED; } } } ``` 在这个例子中，`Order` 类除了包含订单的基本信息，还包含了支付和取消订单的业务逻辑。使用充血模型的好处在于，将与订单相关的业务逻辑都集中在`Order`类中，使得代码结构更加内聚和面向对象。 ### 2. 贫血模型（Anemic Model） 贫血模型指的是实体对象只包含数据属性，而不包含业务逻辑。在这种模型中，业务逻辑通常在服务层或控制器层实现，实体类仅用于存储数据，类似于数据传输对象（DTO）。 #### 贫血模型的特点 - **数据与逻辑分离**：实体类仅存储数据，业务逻辑分散在服务层或控制器层。 - **结构简单**：实体对象只包含数据属性，没有复杂的方法。 - **易于测试**：由于逻辑集中在服务层，测试较为方便。 #### 电商场景中的贫血模型例子 在同样的电商系统中，“订单（Order）”可以被设计为贫血模型。此时，`Order` 类只保存订单的数据，所有的业务逻辑转移到 `OrderService` 中： ```java public class Order { private String orderId; private List<Item> items; private OrderStatus status; // 构造方法和属性的getter/setter省略 } public class OrderService { public void addItem(Order order, Item item) { order.getItems().add(item); } public void removeItem(Order order, Item item) { order.getItems().remove(item); } public void pay(Order order, Payment payment) { if (order.getStatus() == OrderStatus.PENDING) { // 处理支付逻辑 order.setStatus(OrderStatus.PAID); } } public void cancel(Order order) { if (order.getStatus() == OrderStatus.PENDING) { // 取消订单逻辑 order.setStatus(OrderStatus.CANCELLED); } } } ``` 在这个例子中，`Order` 类仅包含数据属性，而所有的业务逻辑都在 `OrderService` 中实现。这样使得实体类变得更简单，但也导致逻辑分散。 ### 总结：充血模型和贫血模型的优劣对比 - **充血模型**：适合需要业务逻辑高度内聚的复杂业务系统。模型更符合面向对象思想，但类职责多，可能会导致复杂性增加。 - **贫血模型**：适合业务逻辑相对简单的系统。模型结构清晰，但容易导致业务逻辑分散，不利于代码维护。 在实际项目中，如果系统复杂度较高、需要内聚业务逻辑时，可以采用充血模型；而在追求简单易维护的项目中，可以使用贫血模型。