在本文中，我將對此做出詳細解釋。

CQS思想

CQS：命令和查詢分離：Command and Query Segregation。

其核心思想是在任何一個對象的方法可以劃分為兩類：

• 查詢：獲取數據，返回查詢數據，但不改變數據狀態。
• 命令：改變數據狀態，不返回任何數據。

CQRS模式的核心設計理念來自于一條設計原則，即單一職責原則。

• 所謂單一職責原則，指的是一個技術組件只應該負責具體一項職責。

而不應該有多個導致該組件發生狀態變化的操作。

基于CQS的思想，任何一個方法都可以拆分為命令和查詢兩部分，如下：

private int data = 0;
private int update(int value) {
    data += value;
    return data;
}

上述方法既改變了數據，又返回了數據狀態。

如果按照CQS的思想，則該方法可以拆成Command和Query兩部分，如下：

private void update(int value) {
    data += value;
}
private int query() {
    return data;
}

對于命令側是否返回數據實際業務訴求中并不一定能夠完全統一。

比如：

• 某些業務場景下可能會有返回業務主鍵的訴求，比如下單操作返回訂單號。

基本原則

CQS的主要原則是：

• 一個方法要么是命令，要么是查詢，但不能兩者兼有。
• 這種分離有助于提高代碼的可讀性和維護性，因為它明確了方法的用途。

CQRS架構

Command and Query Responsibility Segregation

• 即命令查詢職責分離，是一種將命令和查詢的責任明確分離的架構模式。
• 這種模式進一步擴展了CQS的思想，適用于更大規模的系統架構。

架構思想：

CQRS將系統的讀操作和寫操作分離到不同的模型中：

• 命令模型（Command Model）：

處理數據的寫操作（創建、更新、刪除）。

• 查詢模型（Query Model）：
• 處理數據的讀操作（查詢）。

這種分離可以通過不同的數據模型、數據庫甚至服務來實現，從而優化讀寫性能和可伸縮性。

CQRS 模式的應用非常簡單，如下圖所示：

圖片

假設服務為 UserService，在非CQRS模式下同時包含了查詢和更新服務接口。

public class UserService {
   //  根據id查詢用戶
    UserId getUserId(int userId);
    // 更新用戶
    void updateUser(User user);
}

應用CQRS模式之后的UserService被拆分成了兩個接口，分別承擔查詢和寫職責。

/**
   命令服務
*/
public class UserCommandService {
    void updateUser(UserCommand command);
}
/**
   查詢服務
*/
public class UserQueryService{
    User getUserById(int userId);
}

最終一致性

采用CQRS后，查詢和命令兩側通常會采用獨立的數據模型。

• 采用CQRS模式并沒有強制要求必須要進行數據模型的分離。

在這種架構模式下，命令側的數據變化后及時同步（事件、消息隊列）到查詢側，兩側數據并非實時。

• 在一定的延時后兩側數據最終達成一致。

圖片

最后總結

CQRS的使用者可以根據實際情況，將讀寫分離開單獨部署，然后引入領域事件，使用消息隊列做通信。

• 但是這些都是基于不同業務場景的架構選擇，而非CQRS本身的要求。
• 實際上CQRS只是一種非常簡單的模式而已，并沒有和事件、消息隊列這些有強關聯。

讀寫分離部署+消息通信：

• 會帶來額外的系統復雜性和更高的運維成本。

《重構：改善既有代碼的設計》的作者也提醒要小心使用CQRS，不推薦將CQRS復雜化處理。