领域驱动设计(DDD)【26】之CQRS模式初探

一 CQRS初探：理解基本概念

1.1 什么是CQRS？

• Greg Young把增、删、改功能称为 Command（命令），把查询称为 Query，这两种功能的职责不同，应该采用不同的方式来处理，因此叫做“命令查询职责分离”（Command Query Responsibility Segregation ），简称 CQRS。
• CQRS（Command Query Responsibility Segregation，命令查询职责分离）是一种架构模式，它的核心思想是将系统的**写操作（命令）和读操作（查询）**分离，使用不同的模型来处理。
• 想象一下图书馆的管理方式：借书和还书（写操作）由前台工作人员处理，而查询书籍位置或可用性（读操作）则由咨询台负责。这种职责分离提高了效率，这正是CQRS的核心思想。

1.2 CQRS与CRUD的对比

• 传统CRUD（Create, Read, Update, Delete）架构中，读写操作使用同一个数据模型：

而CQRS将读写分离：

1.3 为什么需要CQRS？

• 读写负载不均衡：大多数系统读操作远多于写操作
• 性能优化：可以为读写分别优化
• 简化复杂性：避免单一模型同时满足读写需求带来的妥协
• 扩展性：读写可以独立扩展

二 CQRS深入：架构细节

2.1 基本架构组成

一个典型的CQRS系统包含以下组件：

1. 命令端(Command Side)

   • 处理创建、更新、删除等操作
   • 通过命令(Command)触发
   • 产生领域事件(Domain Events)

2. 查询端(Query Side)

   • 处理数据查询
   • 针对展示需求优化
   • 通常是非规范化的数据视图

3. 同步机制

   • 保持命令端和查询端数据一致性
   • 可通过事件溯源(Event Sourcing)或定期同步实现

---

2.2 数据流示意图

三 CQRS实战：电商订单案例

通过一个电商订单系统来具体理解CQRS的实现。

3.1 传统CRUD方式的订单处理

• 在传统方式中，我们可能会有一个Order类同时处理读写：

public class Order {private Long id;private String customerId;private List<OrderItem> items;private OrderStatus status;private Date createdDate;// 读方法public BigDecimal calculateTotal() {return items.stream().map(i -> i.getPrice().multiply(i.getQuantity())).reduce(BigDecimal.ZERO, BigDecimal::add);}// 写方法public void addItem(Product product, int quantity) {// 验证逻辑...items.add(new OrderItem(product, quantity));}
}

这种方式随着业务复杂化会变得难以维护。

3.2 CQRS方式的订单系统

3.2.1 命令端实现

• OrderCommandService.java (处理写操作)

public class OrderCommandService {private final OrderRepository orderRepository;private final EventPublisher eventPublisher;@Transactionalpublic void createOrder(CreateOrderCommand command) {// 验证业务规则if (command.getItems().isEmpty()) {throw new IllegalArgumentException("订单不能为空");}// 创建聚合根Order order = new Order(command.getOrderId(),command.getCustomerId(),command.getItems());// 保存orderRepository.save(order);// 发布事件eventPublisher.publish(new OrderCreatedEvent(order.getId(),order.getCustomerId(),order.getItems(),order.getStatus()));}public void cancelOrder(CancelOrderCommand command) {// 类似实现...}
}

3.2.2 查询端实现

• OrderQueryService.java (处理读操作)

public class OrderQueryService {private final OrderReadRepository readRepository;public OrderDTO getOrderById(String orderId) {return readRepository.findById(orderId).orElseThrow(() -> new OrderNotFoundException(orderId));}public List<OrderSummaryDTO> getOrdersByCustomer(String customerId) {return readRepository.findByCustomerId(customerId);}
}

3.2.3 读模型DTO

public class OrderDTO {private String orderId;private String customerId;private List<OrderItemDTO> items;private String status;private BigDecimal totalAmount;private Date createdDate;// 仅包含简单getter/setter
}public class OrderSummaryDTO {private String orderId;private String status;private BigDecimal totalAmount;private Date createdDate;private int itemCount;// 仅包含简单getter/setter
}

3.3 数据同步实现

• 使用领域事件同步读写模型：

@Component
public class OrderEventListener {private final OrderReadRepository readRepository;@EventListenerpublic void handleOrderCreated(OrderCreatedEvent event) {OrderDTO orderDTO = new OrderDTO();orderDTO.setOrderId(event.getOrderId());// 其他字段映射...readRepository.save(orderDTO);}@EventListenerpublic void handleOrderCancelled(OrderCancelledEvent event) {OrderDTO order = readRepository.findById(event.getOrderId()).get();order.setStatus("CANCELLED");readRepository.save(order);}
}

四 CQRS进阶：高级话题

4.1 最终一致性处理

由于读写分离，CQRS系统通常是最终一致性的。处理方式包括：

1. 事件驱动的更新：通过领域事件触发读模型更新
2. 补偿事务：当更新失败时执行补偿
3. 版本控制：检测和处理并发冲突

4.2 CQRS的适用场景

CQRS并非银弹，适合以下场景：

• 读写负载差异大的系统
• 复杂领域模型，读写需求差异大
• 需要高性能查询的系统
• 需要审计日志或历史追踪的系统

---

不适合的场景：

• 简单CRUD应用
• 对实时一致性要求极高的系统
• 开发资源有限的小型项目

五 CQRS实践建议

5.1 实施步骤

1. 从简单开始：可以先在单个有界上下文(Bounded Context)中尝试
2. 明确边界：清晰划分命令和查询的边界
3. 渐进式演进：从分离模型开始，逐步引入事件溯源等高级特性

5.2 常见陷阱与解决方案

陷阱	解决方案
过度设计	从实际需求出发，只在必要时引入CQRS
数据不一致	实现健壮的事件处理机制，监控延迟
事件风暴	使用事件溯源时合理设计事件粒度
开发复杂性	提供充分的文档和示例代码

5.3 性能考量

1. 读模型优化：

   • 使用非规范化设计
   • 针对查询场景定制数据结构
   • 考虑使用专门的查询数据库(如Elasticsearch)

2. 写模型优化：

   • 使用聚合根保证一致性边界
   • 合理设计命令处理流程
   • 考虑批处理和异步处理

六 总结

CQRS是一种强大的架构模式，通过分离读写职责可以带来诸多好处：

1. 领域模型更清晰：命令端专注于业务规则，查询端专注于展示需求
2. 性能更优：可以针对读写分别优化和扩展
3. 灵活性更高：可以轻松添加新的查询而不影响命令处理

然而CQRS也带来了额外的复杂性，应该根据项目实际需求谨慎采用。对于初学者，建议从一个小的、非核心的功能开始实践，逐步积累经验。

• 记住，架构模式是工具而非目标，选择适合你项目的最简单有效的方案才是明智之举。