閱讀目錄：
CQRS Journey－微軟示例項目
ENode－netfocus 實(shí)踐項目
存在即是理由，每一種架構的產(chǎn)生都會(huì )有一種特定的場(chǎng)景，或者解決某一種實(shí)際應用問(wèn)題，經(jīng)驗的累積促成了某一種架構的產(chǎn)生。
說(shuō)明：本圖摘自 MSDN
CQRS（Command & Query Responsibility Segregation）命令查詢(xún)職責分離，和 REST 同屬于架構風(fēng)格，如果單純理解 CQRS，是比較容易的，另一種方式解釋就是，一個(gè)方法要么是執行某種動(dòng)作的命令，要么是返回數據的查詢(xún)，命令的體現是對系統狀態(tài)的修改，而查詢(xún)則不會(huì )，職責的分離更加有利于領(lǐng)域模型的提煉，系統的靈活性和可擴展性也得到進(jìn)一步加強。
為什么要進(jìn)行命令和查詢(xún)職責分離？
如果你有時(shí)間，可以先閱讀下上面幾篇博文及相關(guān)評論。
我們都知道 Repository 的職責就是管理聚合根（Aggregate）對象，一般是一一對應關(guān)系，領(lǐng)域層中的業(yè)務(wù)邏輯要對某種聚合根對象進(jìn)行操作，必須要通過(guò) Repository，而應用層接受用戶(hù)請求獲取數據對象顯示，也必須要通過(guò) Repository 進(jìn)行聚合根對象轉換，這個(gè)一般沒(méi)有涉及到領(lǐng)域業(yè)務(wù)操作，僅僅只是獲取聚合根對象數據。領(lǐng)域層中的業(yè)務(wù)邏輯要求 Repository 實(shí)現對聚合根狀態(tài)的管理，所以我們一般會(huì )在領(lǐng)域層 IRepository 接口中定義 Add、Update、GetById 等方法，然后在基礎設施層中的 Repository 進(jìn)行實(shí)現，而來(lái)自應用層的要求，需要獲取聚合根對象數據，所以在 Repository 中還需要添加一些 GetList 等操作，而根據 IRepository 的接口契約，返回的類(lèi)型必須是聚合根，而在這種場(chǎng)景中，是不需要獲取聚合根對象的，只需要獲取數據（DTO）就可以了。。。
我大致列一下上面描述中，所出現的一系列問(wèn)題：
如果你帶著(zhù)這些問(wèn)題去理解 CQRS，就會(huì )有這樣的感慨：“天哪，這簡(jiǎn)直就是老天派下的一個(gè)救星??！”。
回到一開(kāi)始的那張圖上，看起來(lái)感覺(jué)很簡(jiǎn)單的樣子，來(lái)自用戶(hù) UI 的請求分為 Query（查詢(xún)）和 Command（命令），這些請求操作都會(huì )被 Service Interfaces（服務(wù)接口，只是一個(gè)統稱(chēng)）接收，然后再進(jìn)行分發(fā)處理，對于命令操作會(huì )更新 Update Data store，因為讀與寫(xiě)分離，為了保持數據的一致性，我們還需要把數據更新應用到 Read Data store。對于一般的應用系統來(lái)說(shuō)，查詢(xún)會(huì )占很大的比重，因為讀與寫(xiě)分離了，所以我們可以針對查詢(xún)進(jìn)行進(jìn)一步性能優(yōu)化，而且還可以保持查詢(xún)的靈活性和獨立性，這種方式在應對大型業(yè)務(wù)系統來(lái)說(shuō)是非常重要的，從這種層面上來(lái)說(shuō)，CQRS 不用于 DDD 架構好像也是可以的，因為它是一種風(fēng)格，并不局限于一種架構實(shí)現，所以你可以把它有價(jià)值的東西進(jìn)行提煉，應用到合適的一個(gè)架構系統中也是可以的。
如果 CQRS 中包含有 Domain（領(lǐng)域）的概念，會(huì )是怎樣的一種情形呢？
說(shuō)明：本圖摘自 AxonFramework
上面圖中包含有很多的概念，但本質(zhì)是和第一張圖是一樣的，只不過(guò)在其基礎上進(jìn)行了擴展和延伸，先列舉一下所涉及的概念：
上面有些是 EDA（事件驅動(dòng)架構）中的概念，這個(gè)在后面會(huì )有詳細說(shuō)明，我簡(jiǎn)單描述一下處理流程，首先抽離兩個(gè)重要概念：Command（命令）和 Event（事件），Command 是一種命令的語(yǔ)氣（本身就是命令的意思，呵呵），它的效果就是對某種對象狀態(tài)的修改，Command Bus 收集來(lái)自 UI 的 Command 命令，并根據具體命令分發(fā)給具體的 Command Handler 進(jìn)行處理，這時(shí)候就會(huì )產(chǎn)生一些領(lǐng)域操作，并對相應的領(lǐng)域對象進(jìn)行修改，Command Handler 只是修改操作，并不會(huì )涉及到修改之后的操作（比如保存、事件發(fā)布等），Command Handler 完成之后并不表示這個(gè) Command 命令就此結束，它需要把接下來(lái)的操作交給 Event Bus（完成之后的操作），并分發(fā)給相應的 Event Handler 訂閱者進(jìn)行處理，一般是數據保存、事件存儲等。
我們來(lái)看 IDDD 中的一段代碼（P126）：
public void commitBacklogItemToSprint( String aTenantId, String aBacklogItemId, String aSprintId) { TenantId tenantId = new TenantId(aTenantId); BacklogItem backlogItem = backlogItemRepository().backlogItemOfId( tenantId, new BacklogItemId(aBacklogItemId)); Sprint sprint = sprintRepository().backlogItemOfId( tenantId, new SprintId(aSprintId)); backlogItem.commitTo(sprint);}commitBacklogItemToSprint 就可以看作是一個(gè) Command Handler，注意其命名（commitXXXXToXXXX），一眼看過(guò)去就是命令的意思，commitTo 之后的操作是提交給 Event Bus，然后分發(fā)給相應 Event Handler 訂閱者，來(lái)完成狀態(tài)修改后確定的操作，這樣一個(gè)領(lǐng)域對象狀態(tài)的變更才算完成。
關(guān)于 Event Handler 保存領(lǐng)域狀態(tài)操作，其實(shí)說(shuō)簡(jiǎn)單也簡(jiǎn)單，說(shuō)復雜會(huì )很復雜，對于它的實(shí)現一般會(huì )采用異步的方式，也就是說(shuō)領(lǐng)域狀態(tài)的保存操作不會(huì )延時(shí)領(lǐng)域中的業(yè)務(wù)操作，數據的一致性使用 Unit of Work，具體的領(lǐng)域狀態(tài)保存用 Repository 實(shí)現。
梳理 Command 整個(gè)流程，你會(huì )發(fā)現一個(gè)關(guān)鍵詞：狀態(tài)（Status），在上一篇博文講 REST 概念時(shí)，也有一個(gè)相似的概念：應用狀態(tài)（Application State），REST 其中的一個(gè)含義就是狀態(tài)轉換，從客氣端的發(fā)起請求開(kāi)始，到服務(wù)端響應請求結束，應用狀態(tài)在其過(guò)程中會(huì )進(jìn)行不斷的轉換，請求響應的整個(gè)過(guò)程也就是應用狀態(tài)轉換的過(guò)程，對于 Command 處理流程來(lái)說(shuō)，領(lǐng)域對象的狀態(tài)和應用狀態(tài)其實(shí)是相類(lèi)似。我舉一個(gè)例子，在 REST 架構風(fēng)格中，應用狀態(tài)是不會(huì )保存到服務(wù)端的，客戶(hù)端發(fā)起請求（包含應用狀態(tài)信息），服務(wù)端做出相應處理，此時(shí)的狀態(tài)會(huì )轉換成資源狀態(tài)呈現給客戶(hù)端，這就是表現層狀態(tài)轉換的意思，回到 Command 處理流程上，Command Bus 接收來(lái)自 UI 的請求，分發(fā)給相應的 Command Handler 進(jìn)行處理，在處理過(guò)程中，就會(huì )對領(lǐng)域對象進(jìn)行修改操作，但它不會(huì )保存修改之后的狀態(tài)信息，而是交給 Event Handler 進(jìn)行保存狀態(tài)信息。
和 Command 相比，Query 的處理流程就簡(jiǎn)單很多了，Query Service 接收來(lái)自 UI 的查詢(xún)請求，這個(gè)查詢(xún)處理可以用各種方式實(shí)現，你可以使用 ORM，也可以直接寫(xiě) SQL 代碼，反正是：怎么能提高性能，就怎么來(lái)！返回的結果類(lèi)型一般是 DTO（數據傳輸對象），根據 UI 進(jìn)行設計，可以減少不必要的數據傳輸。
Event-Driven Architecture（事件驅動(dòng)架構），來(lái)自解道的定義：
事件代表過(guò)去發(fā)生的事件，事件既是技術(shù)架構概念，也是業(yè)務(wù)概念，以事件為驅動(dòng)的編程模型稱(chēng)為事件驅動(dòng)架構 EDA。
EDA 架構的三個(gè)特性：
EDA 架構的核心是基于消息的發(fā)布訂閱模式，通過(guò)發(fā)布訂閱模式實(shí)現事件的一對多靈活分發(fā)。消息消費方對發(fā)送方而言完全透明，消息發(fā)送方只管把消息發(fā)送到消息中間件，其它事情全部不用關(guān)心，由于消息中間件中的 MQ 等技術(shù)，即使發(fā)送消息時(shí)候，消息接收方不可用，但仍然可以正常發(fā)送，這才叫徹底解耦。其次一對多的發(fā)布訂閱模式也是一個(gè)核心重點(diǎn)，對于消息的訂閱方和訂閱機制，可以在消息中間件靈活的進(jìn)行配置和管理，而對于消息發(fā)送方和發(fā)送邏輯基本沒(méi)有任何影響。
EDA 要求我們的是通過(guò)業(yè)務(wù)流程，首先要識別出有價(jià)值的業(yè)務(wù)事件，這些事件符合異步、實(shí)時(shí)和發(fā)布訂閱等基本的事件特征；其次是對事件進(jìn)行詳細的分析和定義，對事件對應的消息格式進(jìn)行定義，對事件的發(fā)布訂閱機制進(jìn)行定義等，最后才是基于消息事件模式的開(kāi)發(fā)和測試等工作。
在上一篇博文中有講到 SOA，我們知道分為客戶(hù)端和服務(wù)端，客戶(hù)端發(fā)起請求給服務(wù)端，服務(wù)端做出相應的響應，也就是說(shuō)客戶(hù)端是主動(dòng)的，服務(wù)端是被動(dòng)的，這種情況就會(huì )造成服務(wù)的分散，也就是說(shuō)，我們一般在設計服務(wù)的時(shí)候，會(huì )根據客戶(hù)端的響應而被迫的切分業(yè)務(wù)邏輯，最后導致的情況是各個(gè)業(yè)務(wù)模塊所屬的服務(wù)，被分散在各個(gè)業(yè)務(wù)系統中，這種設計就會(huì )導致很多問(wèn)題的發(fā)生。而對于 EDA 架構來(lái)說(shuō)，訂閱者向 Event Bus 訂閱事件，告訴事件總線(xiàn)我要這個(gè)，而 Event Bus 接收訂閱后，并不會(huì )立即進(jìn)行處理，而是想什么時(shí)候處理就什么時(shí)候處理，主動(dòng)權在 Event Bus 手中，當 Event Bus 想進(jìn)行處理的時(shí)候，一般是接受來(lái)自 Command Handler 的請求，然后就分別向指定訂閱者發(fā)布通知，告訴它們我已經(jīng)處理了，你們可以接著(zhù)做下面的事了。
從上面的描述中，我們可以看到 SOA 和 EDA 的明顯區別，相對于 SOA 來(lái)說(shuō)，EDA 更加有利于領(lǐng)域的聚合，主動(dòng)權在領(lǐng)域手中，我們就可以從容面對很多的情形，簡(jiǎn)單畫(huà)了一張圖：
另外，需要注意的一點(diǎn)，CQRS 可以結合 EDA，也可以不結合，但反過(guò)來(lái)對于 EDA 來(lái)說(shuō)，則必須結合 CQRS 使用。
領(lǐng)域事件和 Domain Service（領(lǐng)域服務(wù)）一樣，同屬于 DDD 戰術(shù)模式，這部分內容在 IDDD 第八章有詳細介紹，因為我還沒(méi)學(xué)習到那部分，這邊就簡(jiǎn)單說(shuō)明一下。在 EDA 的定義中說(shuō)到：事件代表過(guò)去發(fā)生的事件，換句話(huà)說(shuō)它是代表已完成的事件，準備來(lái)說(shuō)，還應該包含正在完成的事件，既然是屬于 DDD 戰術(shù)模式的一種，那在領(lǐng)域設計中必然有所用武之地。
我用大白話(huà)來(lái)描述下領(lǐng)域事件在領(lǐng)域中的作用：我們知道行軍打仗需要做出抉擇，也就是說(shuō)，需要指揮部商量后下達作戰命令，然后把命令交給各個(gè)負責的作戰中心，有陸軍、海軍、空軍、導彈部隊等，它們是命令的實(shí)施者，而指揮部是命令的決策者，這個(gè)和領(lǐng)域事件是一樣的，領(lǐng)域中處理一些業(yè)務(wù)邏輯后，就會(huì )對領(lǐng)域對象的狀態(tài)做出一些改變，這個(gè)就相當于作戰命令，然后根據作戰命令分配的作戰中心進(jìn)行完成，也就是領(lǐng)域事件的訂閱者去完成領(lǐng)域對象狀態(tài)改變之后的操作，簡(jiǎn)單而言，領(lǐng)域事件就是領(lǐng)域中的“跑腿者”。
在上面 EDA 的介紹中，有這樣的一段代碼：backlogItem.commitTo(sprint);，用通用語(yǔ)言表述就是：待定項提交到?jīng)_刺，這是領(lǐng)域中完成的一個(gè)操作，由 Command Handler 進(jìn)行委派完成，backlogItem 是一個(gè)聚合根對象，commitTo 是聚合根中的一個(gè)操作，這個(gè)操作完成后，backlogItem 聚合根對象的狀態(tài)就會(huì )被修改了，那在 commitTo 中具體有怎么的操作呢？看下示例代碼：
public void commitTo(Sprint aSprint){ this.assertArgumentNotNull(aSprint, "Sprint must not be null."); this.assertArgumentEquals(aSprint.tenantId(), this.tenantId(), "Sprint must be of same tenant."); this.assertArgumentEquals(aSprint.productId(), this.productId(), "Sprint must be of same product."); if (!this.isScheduledForRelease()) { throw new IllegalStateException("Must be scheduled for release to commit to sprint."); } if (this.isCommittedToSprint()) { if (!aSprint.sprintId().equals(this.sprintId())) { this.uncommitFromSprint(); } } this.elevateStatusWith(BacklogItemStatus.COMMITTED); this.setSprintId(aSprint.sprintId()); DomainEventPublisher .instance() .publish(new BacklogItemCommitted( this.tenantId(), this.backlogItemId(), this.sprintId()));}注意 commitTo 所處在 BacklogItem 聚合根內，前面都是對聚合根對象的一些狀態(tài)操作，在后面我們會(huì )看到 DomainEventPublisher（領(lǐng)域事件發(fā)布者），BacklogItemCommitted 繼承自 DomainEvent，BacklogItemCommitted 對應的領(lǐng)域事件，在 BacklogItemApplicationService 中進(jìn)行訂閱，一般是聚合根對象在初始化的時(shí)候。
根據上面這個(gè)代碼示例，然后結合 EDA 的三個(gè)特性就可以很好理解了，首先對于領(lǐng)域事件的處理操作一般是異步完成，這樣就不會(huì )影響聚合根中的其他業(yè)務(wù)操作，當領(lǐng)域事件發(fā)布的時(shí)候，會(huì )實(shí)時(shí)的告知訂閱者進(jìn)行處理，因為它不管訂閱者的具體處理情況，訂閱者和發(fā)布者的規范在 DomainEvent 中，而不是像接口定義和實(shí)現那么強制，所以，當領(lǐng)域事件發(fā)布的時(shí)候，就說(shuō)明訂閱者已經(jīng)被告知并進(jìn)行了處理，所以他們直接的關(guān)系可以徹底的解耦。
在之前的短消息項目中，我沒(méi)用到領(lǐng)域事件，對它也不是很深入的了解，在后面的博文中，再進(jìn)行詳細說(shuō)明。
來(lái)自 IDDD 中的定義：
事件驅動(dòng)的、分布式的并行處理模式。
關(guān)于 Saga 的相關(guān)博文，國內幾乎沒(méi)有（netfocus 有一篇相關(guān)說(shuō)明），長(cháng)時(shí)處理過(guò)程，說(shuō)明它是一個(gè)需要耗時(shí)、多任務(wù)并行的處理過(guò)程，那在領(lǐng)域中，什么時(shí)候會(huì )有它的用武之地呢？比如一個(gè)看似簡(jiǎn)單的業(yè)務(wù)邏輯，可能會(huì )涉及到領(lǐng)域中很復雜的業(yè)務(wù)操作，而且對于這些處理需要耗費很長(cháng)的時(shí)間。
在電子商城提交一個(gè)訂單操作，用戶(hù)看來(lái)可能會(huì )非常簡(jiǎn)單，但在領(lǐng)域進(jìn)行處理的時(shí)候，會(huì )涉及到訂單操作、客戶(hù)操作、商品操作、庫存操作、消息通知操作等等，有些會(huì )進(jìn)行及時(shí)的處理，但有些則不會(huì )，比如消息通知操作等等，我們可以把這個(gè)業(yè)務(wù)操作分離一下，對于一些耗時(shí)比較長(cháng)的操作精揀一下，商品的減少對應庫存的減少，減少之后會(huì )進(jìn)行警戒線(xiàn)判斷，如果低于警戒下，則會(huì )給庫存管理人員發(fā)送消息，商品減少了對應的商品統計也要進(jìn)行更新，客戶(hù)購買(mǎi)之后也要進(jìn)行發(fā)送消息通知，我們可以把這些用一個(gè) Saga 進(jìn)行處理，因為是基于事件驅動(dòng)，所以一個(gè) Saga 中會(huì )訂閱多個(gè)事件，Saga 會(huì )對這些事件進(jìn)行跟蹤，對于一些事件處理失敗，也要進(jìn)行做出相應的彌補措施，當所有的操作完成后，Saga 會(huì )返回一個(gè)狀態(tài)給領(lǐng)域，也許這個(gè)返回操作已經(jīng)在開(kāi)始的幾天以后了。
說(shuō)明：本圖摘自 MSDN
上圖描述的是：一個(gè)會(huì )議購買(mǎi)座位的業(yè)務(wù)過(guò)程，中間的 Order Process Manager 就是一個(gè) Saga，在 CQRS 架構中的表現就是 Process Manager（過(guò)程管理），我們一般會(huì )用它處理多個(gè)聚合根交互的業(yè)務(wù)邏輯，比如 netfocus 博文中列舉的 TransferProcessCommandHandlers 操作，還有上圖中的購買(mǎi)座位業(yè)務(wù)操作，那我們應該怎么設計 Saga 呢？或者說(shuō)在設計的時(shí)候，應該需要注意哪些地方呢？我大致列一下：
字面上的理解：
事件即 Event，溯是一個(gè)動(dòng)詞，可以理解為追溯的意思，源代表原始、源頭的意思，合起來(lái)表示一個(gè)事件追蹤過(guò)程。
我們都知道在源代碼管理的時(shí)候，可以使用 SVN、Git、CVS 進(jìn)行對代碼修改的跟蹤操作，從一個(gè)代碼文件的創(chuàng )建開(kāi)始，我們可以查看各個(gè)版本對代碼的修改情況，甚至可以指定版本進(jìn)行還原操作，這就是對代碼跟蹤所帶來(lái)的好處。而對于領(lǐng)域對象來(lái)說(shuō)，我們也應該知曉其整個(gè)生命周期的演變過(guò)程，這樣有利于查看并還原某一“時(shí)刻”的領(lǐng)域對象，在 EDA 架構中，對于領(lǐng)域對象狀態(tài)的保存是通過(guò)領(lǐng)域事件進(jìn)行完成，所以我們要想記錄領(lǐng)域對象的狀態(tài)記錄，就需要把領(lǐng)域對象所經(jīng)歷的所有事件進(jìn)行保存下來(lái)，這就是 Event Store（事件存儲），這個(gè)東西就相當于 Git 代碼服務(wù)器，存儲所有領(lǐng)域對象所經(jīng)歷的事件，對于某一事件來(lái)說(shuō)，可以看作是對應領(lǐng)域對象的“快照”。
總的來(lái)說(shuō)，ES 事件溯源可以概括為兩點(diǎn)：
最后，貼一張 CQRS、EDA、Saga、ES 結合圖：
說(shuō)明：本圖來(lái)自 netfocus
CQRS 參考資料：
EDA 參考資料：
未完成的兩點(diǎn)：
本來(lái)還想把這兩個(gè)項目分析一下，至少可以看懂一個(gè)業(yè)務(wù)流程，比如 Conference 項目中的 AssignSeats、ConferencePublish 等，ENode 項目中的 BankTransferSample 示例，但分析起來(lái)，真的有些吃力，有時(shí)候概念是一方面，實(shí)踐又是另一方面，后面有時(shí)間理解了，再把這兩點(diǎn)內容進(jìn)行補充下。
這篇博文內容有點(diǎn)虛，大家借鑒有用的地方就行，也歡迎拍磚斧正。
聯(lián)系客服
