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

CQS思想

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

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

• 查詢：獲取數(shù)據(jù)，返回查詢數(shù)據(jù)，但不改變數(shù)據(jù)狀態(tài)。
• 命令：改變數(shù)據(jù)狀態(tài)，不返回任何數(shù)據(jù)。

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

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

而不應該有多個導致該組件發(fā)生狀態(tài)變化的操作。

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

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

上述方法既改變了數(shù)據(jù)，又返回了數(shù)據(jù)狀態(tài)。

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

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

對于命令側是否返回數(shù)據(jù)實際業(yè)務訴求中并不一定能夠完全統(tǒng)一。

比如：

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

基本原則

CQS的主要原則是：

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

CQRS架構

Command and Query Responsibility Segregation

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

架構思想：

CQRS將系統(tǒng)的讀操作和寫操作分離到不同的模型中：

• 命令模型（Command Model）：

處理數(shù)據(jù)的寫操作（創(chuàng)建、更新、刪除）。

• 查詢模型（Query Model）：
• 處理數(shù)據(jù)的讀操作（查詢）。

這種分離可以通過不同的數(shù)據(jù)模型、數(shù)據(jù)庫甚至服務來實現(xiàn)，從而優(yōu)化讀寫性能和可伸縮性。

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

圖片

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

public class UserService {
   //  根據(jù)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后，查詢和命令兩側通常會采用獨立的數(shù)據(jù)模型。

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

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

• 在一定的延時后兩側數(shù)據(jù)最終達成一致。

圖片

最后總結

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

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

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

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

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