有不少網友仍然對CQRS與事件溯源（Event Sourcing）不是很了解，對經典的應用系統架構與CQRS架構之間的差別沒有一個大概的認識。本文基本上摘自Greg Young的CQRS Documents一文（由daxnet本人翻譯并做了簡要的注釋），希望能夠對應用系統架構的愛好者有所幫助。

【注：本文主體內容節選并翻譯自Greg Young的CQRS Documents。如需查看原文，請單擊此處】

一、經典的應用系統結構

在了解基于領域驅動設計（Domain Driven Design, DDD）的應用系統之前，首先讓我們了解一下經典的應用系統結構。這種經典的應用系統結構往往被認定為設計與開發分布式應用系統的一種標準化方案，下圖描述了這種經典的應用系統結構。

上面的架構依賴于一個后臺的數據存儲系統。雖然通常情況下是一個關系型數據庫，但這種數據存儲系統可以用多種方式實現，比如采用鍵值存儲、對象數據庫或者甚至是XML文件。不管怎么樣，這個數據存儲系統保存的是領域模型中對象的當前狀態。在數據存儲系統的上層，就是整個系統的核心部分：應用服務器（Application Server）。在應用服務器中，有一個稱之為“Domain”的部分，它包含了整個系統的業務邏輯，比如對來自于外部請求的業務驗證等邏輯。于此同時，“應用服務”也是應用服務器中的一部分，它向外界提供了訪問領域模型的接口，同時在調用者與領域模型之間實現了解耦。再外層就是Remote Facade，它通常可以是SOAP、定制的TCP/IP通信、通過HTTP進行傳輸的XML文檔、TomCat，或者是輸入數據的工作人員。Remote Facade的主要職責是為外部系統與應用服務器之間的交互提供遠程代理和橋梁的作用。整個應用服務器的作用是對后臺數據存儲系統進行抽象與解耦，同時對整個系統的業務邏輯進行處理。這樣的經典架構曾經非常流行，而且即便是現在，絕大部分系統仍然將其作為默認的首選架構風格。

現在讓我們分析一下這樣的經典應用系統結構。這樣的架構有很多特點，當然，其中一些特點在某些應用場合表現得非常不錯，而也有一些特定卻無法適應其它的一些應用場合。作為架構師，我們需要善于總結和發現，使得所選架構能夠最大程度地滿足系統需求。

• 簡單
  這種經典的應用系統結構給我們帶來的一個最大的特點就是簡單。初級程序員可以很快地掌握這種系統結構并快速地了解到整個系統中各個部分是如何銜接和通訊的。“簡單”又帶來了這種架構風格的另一個特性，就是“通用”。它能夠被用到絕大部分項目上，于是，這種架構風格也就成為了大家討論系統架構的“通用語言”：說起分層，就是經典的三層（或者四層，或者五層，但不外乎就是UI層、業務層和數據層）；說起數據存儲系統，就是關系型數據庫，馬上也就聯想到表、字段、約束、存儲過程等等。這種“通用”的特性帶來一個好處：開發人員對系統上手很快，比如某個項目新來了一名開發人員，他可以在短時間里熟悉系統結構和開發過程，這在一定程度上節省了項目的開支
• 工具化、框架化
  由于“簡單”和“通用”，于是，開發一套“通用”的支持經典架構的應用系統開發的工具/框架，就變得相對容易。目前已經有很多現成的框架，通過使用這些框架能夠方便、快捷地搭建這種經典架構的應用系統。比如ORM，它提供了領域對象與關系型數據庫的映射處理，在系統中引入ORM，開發人員就不需要自己去維護這種映射關系，大大提高了開發效率，節省了開發成本
• 領域驅動
  在這種經典的應用系統結構上實踐領域驅動設計是不可能的事情，即使之前有不少人試圖通過這種架構來實踐領域驅動（daxnet：之前我也認為DDD可以在這種架構上實踐，而且從實現角度來看，并沒有什么是行不通的，然而Greg Young卻并不認同，原因是由于通用語言，當然Greg Young也不一定是完全正確的，但他要比我們實踐的更多，他的推斷更具參考價值，我們還需要在實踐中去體會這種差別）。其原因簡單地說就是這種架構中的對象模型無法正確地表述成通用語言。我們不難發現，這種經典的架構中，只有四種謂詞：新建（Create）、讀取（Read）、更新（Update）和刪除（Delete），也就是我們常說的CRUD。由于Remote Facade是面向數據的（也就是面向DTO的），于是，Application Service也就需要提供相同的面向數據的接口。這也就意味著，領域模型也只能支持這四種謂詞；而當我們跟領域專家進行交流的時候，我們往往采用的是“通用語言”，而通用語言的內容就很豐富了，完全不僅僅是這四種謂詞
• 項目規模
  當我們深入地去了解這種架構的時候，我們會發現，當項目規模變得很大的時候，有一個非常大的瓶頸，就是數據存儲系統。尤其是關系型數據庫。當然，雖然現在90%以上的系統采用的是關系型數據庫，但是項目規模的擴大畢竟也不是一種常態，因此，這種瓶頸的存在也不會是什么太大的問題

總之，經典的應用系統結構能夠適用于絕大多數的系統開發，它有著最大的優點，就是簡單。然而，它不適應于基于領域驅動設計的項目開發，如果你非要在這樣的架構下實踐領域驅動，那必定是失敗的。

二、CQRS與事件溯源

CQRS與事件溯源有著相輔相成的關系。CQRS允許事件溯源作為領域的數據存儲機制。然而，使用事件溯源的一個最大的缺點是，你無法向你的系統提出類似“請告訴我所有名字為Greg的用戶”這樣的問題，這是由于事件溯源無法提供對象的當前狀態而引起的。CQRS唯一支持的查詢就是：GetById - 通過ID來獲得某個聚合。下圖為基于CQRS的應用系統結構，可以與上圖的經典結構作一個對比。

對比兩種不同風格的系統架構，我們發現，兩者在客戶端（Client）所需要投入的工作量大體上是相同的，因為兩種不同架構下的客戶端所做的操作大體相同：從系統獲得DTO，將DTO轉換為View Model并顯示在UI上，接收用戶輸入，產生命令，然后通知應用系統做相應的操作。在查詢功能的實現上，這兩種系統架構所花費的成本也大體相同：在經典的應用系統結構中，查詢是建立在領域模型上的，而在CQRS結構的應用系統中，查詢則是另外一件事情：它由一個簡單的讀取訪問層（Thin Read Layer）提供，而這個讀取訪問層會直接將數據映射在DTO上。通過對“命令與查詢職責分離”的討論，實現一個簡單的讀取訪問層不會花費更大的成本，相反，在很多情況下會節省成本開支。

仍然從成本的角度考慮，這兩種系統架構的最大區別應該是在領域模型及其持久化的部分。在經典的架構風格中，為了將領域模型持久化到數據庫，通常情況下ORM承擔了大量的工作，但這同時也在領域模型與持久化機制之間產生了“阻抗失衡”，這種效應最終導致在生產環境中產生了高額成本支出，同時，開發人員也需要更豐富的知識與更多的經驗來處理由“阻抗失衡”導致的問題。在CQRS的架構風格中，從C部分（Command部分）來看，就不會存在這種“阻抗失衡”效應。領域模型產生事件，而數據存儲系統則保存這些事件，領域模型所關注的僅僅就是這些事件而已。然而在Q部分（Query部分），則會產生“阻抗失衡”：事件處理器（Event Handlers）需要根據事件的具體數據來更新Query Database，這里的阻抗失衡產生于事件與數據關系模型之間。然而，Query部分的阻抗失衡效應要遠小于由領域模型與關系型數據庫之間產生的阻抗失衡效應，而且Query部分的阻抗失衡效應要更容易處理和解決。這是因為，事件本身是沒有結構的，它僅僅表述對關系模型應該采取哪些措施。

從以上幾點考慮，這兩種不同風格的系統架構所要完成的工作量幾乎是等同的，并不存在額外的工作量，也不存在更少的工作量。這是兩件完全不同的工作。在建模的時候，基于CQRS架構風格的應用系統似乎有一些額外的工作要做，因為你需要定義一系列的事件對象，同時還要編寫事件處理器；但這種工作量相對而言還是比較小的，它有效地降低了甚至避免了“阻抗失衡”效應。總而言之，事實上在大多數情況下，基于CQRS與事件溯源的應用系統更節約成本，而且更加高效。

三、簡單總結

仍然不要因為感覺CQRS看上去更“先進”，就去生搬硬套，這只能給你帶來失敗的教訓。還是要根據項目的實際情況對整個系統的架構與技術選型作出準確的判斷，這也是架構師的主要職責所在。雖然我的博客中大部分內容都在討論領域驅動設計與CQRS，但這并不表示我會去抵制經典的架構風格，我也同樣在經典的應用系統結構上不斷地學習和思考，我只是希望能夠通過博客這么一種東西，來整理一些新鮮的事物，同時也幫助軟件設計與架構的愛好者們開拓視野，豐富知識。