企业官网建设流程全解析

1. 贫血模型与充血模型概念解析

在传统Java企业级开发中，贫血模型（Anemic Domain Model）是最常见的架构模式。这种模式下，领域对象仅仅是数据载体，所有业务逻辑都集中在Service层。比如一个典型的贫血模型User类：

public class User { private Long id; private String username; private String password; // 只有getter/setter }

与之相对的充血模型（Rich Domain Model）则是DDD（领域驱动设计）的核心实践，要求将数据和操作数据的行为封装在同一个类中。同样的User类在充血模型中会是这样：

public class User { private Long id; private String username; private String password; public void changePassword(String newPassword) { if (newPassword.length() < 8) { throw new IllegalArgumentException("密码长度不能少于8位"); } this.password = encrypt(newPassword); } private String encrypt(String raw) { // 加密逻辑 } }

关键区别：贫血模型的业务逻辑散落在各个Service中，而充血模型的业务逻辑内聚在领域对象内部。根据Martin Fowler的观点，贫血模型本质上是反模式，因为它违背了面向对象"数据与行为封装"的基本原则。

2. 两种模型的实战对比

2.1 订单处理案例对比

假设我们要实现一个电商订单系统，对比两种实现方式：

贫血模型实现：

// Order.java public class Order { private Long id; private BigDecimal amount; private OrderStatus status; // getters/setters } // OrderService.java public class OrderService { public void cancelOrder(Long orderId) { Order order = orderRepository.findById(orderId); if (order.getStatus() != OrderStatus.PAID) { throw new IllegalStateException("只有已支付订单能取消"); } order.setStatus(OrderStatus.CANCELLED); orderRepository.save(order); inventoryService.releaseStock(order); notificationService.sendCancelNotice(order); } }

充血模型实现：

// Order.java public class Order { private Long id; private BigDecimal amount; private OrderStatus status; public void cancel(InventoryService inventory, NotificationService notify) { if (this.status != OrderStatus.PAID) { throw new IllegalStateException("只有已支付订单能取消"); } this.status = OrderStatus.CANCELLED; inventory.releaseStock(this); notify.sendCancelNotice(this); } } // 调用方 order.cancel(inventoryService, notificationService);

2.2 复杂度对比表

3. Spring中的充血模型实践

3.1 依赖注入难题与解决方案

在充血模型中，领域对象需要基础设施服务（如Repository），但Spring默认不管理领域对象的生命周期。有几种解决方案：

方案1：方法参数传递（推荐）

public class Order { public void cancel(OrderRepository repo) { //... repo.save(this); } }

方案2：Domain Service注入

@Service public class OrderDomainService { @Autowired private OrderRepository repo; public void cancel(Order order) { order.cancel(repo); } }

方案3：Spring AspectJ LTW（复杂但优雅）

@Configurable public class Order { @Autowired private transient OrderRepository repo; public void cancel() { // 直接使用repo } }

需要在启动类加@EnableSpringConfigured，并配置AspectJ织入。

3.2 事务管理策略

充血模型中的事务边界需要特别设计：

1. 领域服务作为事务门面

@Service @Transactional public class OrderManager { public void cancelOrder(Long id) { Order order = repo.findById(id); order.cancel(repo); // 事务在此方法生效 } }

2. 聚合根统一管理

public class OrderAggregate { @Transactional public void cancelOrder(Long id) { // 聚合根内协调多个领域对象 } }

实践经验：对于复杂业务，建议采用"领域对象+领域服务"的混合模式。核心领域逻辑放在充血模型中，跨领域协调由领域服务处理。

4. 实际项目迁移指南

4.1 渐进式改造步骤

1. 识别核心领域：从业务复杂度最高的模块开始（如订单、支付）
2. 定义聚合边界：明确哪些对象应该作为一个整体修改
3. 提取领域方法：

   // 改造前 public void updateProductPrice(Long id, BigDecimal price) { Product product = productRepository.findById(id); if (price.compareTo(product.getCost()) < 0) { throw new IllegalArgumentException("价格不能低于成本"); } product.setPrice(price); } // 改造后 public class Product { public void updatePrice(BigDecimal newPrice, BigDecimal cost) { if (newPrice.compareTo(cost) < 0) { throw new IllegalArgumentException("价格不能低于成本"); } this.price = newPrice; } }

4. 重构服务层：将业务逻辑逐步迁移到领域对象

4.2 常见陷阱与解决方案

问题1：领域对象过于臃肿

• 症状：一个领域类有几十个方法
• 解决：按单一职责拆分，或引入领域服务

问题2：循环依赖

• 症状：Order引用Product，Product又引用Order
• 解决：通过ID引用而非对象引用，或引入聚合根

问题3：性能问题

• 症状：加载整个聚合导致查询缓慢
• 解决：使用懒加载或CQRS模式

5. 架构演进建议

对于不同阶段的项目：

1. 新建项目：直接采用充血模型，建立清晰的领域层

   @Entity public class Blog { public void publish() { this.status = PUBLISHED; this.publishTime = LocalDateTime.now(); } }

2. 遗留系统改造：

   • 先在新功能中使用充血模型
   • 逐步重构高价值模块
   • 建立防腐层隔离新旧代码

3. 微服务架构：

   • 每个服务内部使用充血模型
   • 服务间通过DTO或事件通信
   • 考虑事件风暴建模

6. 性能优化技巧

1. 懒加载策略：

   public class Order { @Transient private OrderRepository repo; @ManyToOne(fetch = LAZY) private Customer customer; }

2. 批量处理模式：

   public class OrderBatch { private List<Order> orders; public void bulkCancel() { orders.forEach(Order::markAsCancelled); } }

3. 缓存集成：

   public class Product { @Cacheable("products") public static Product getById(ProductRepository repo, Long id) { return repo.findById(id); } }

在实际项目中，我们通过充血模型将订单核心逻辑的代码量减少了40%，同时使业务规则的单元测试覆盖率从30%提升到了85%。特别是在处理复杂的促销规则时，将各种优惠计算逻辑封装在Promotion领域对象中，使得业务逻辑的修改更加局部化。