一 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也帶來了額外的復雜性，應該根據項目實際需求謹慎采用。對于初學者，建議從一個小的、非核心的功能開始實踐，逐步積累經驗。

• 記住，架構模式是工具而非目標，選擇適合你項目的最簡單有效的方案才是明智之舉。