有不少網友仍然對cqrs與事件溯源（event sourcing）不是很了解，對經典的應用系統架構與cqrs架構之間的差別沒有乙個大概的認識。本文基本上摘自greg young的cqrs documents一文（由daxnet本人翻譯並做了簡要的注釋），希望能夠對應用系統架構的愛好者有所幫助。
單擊此處
】
一、經典的應用系統結構
在了解基於領域驅動設計（domain driven design, ddd）的應用系統之前，首先讓我們了解一下經典的應用系統結構。這種經典的應用系統結構往往被認定為設計與開發分布式應用系統的一種標準化方案，下圖描述了這種經典的應用系統結構。
現在讓我們分析一下這樣的經典應用系統結構。這樣的架構有很多特點，當然，其中一些特點在某些應用場合表現得非常不錯，而也有一些特定卻無法適應其它的一些應用場合。作為架構師，我們需要善於總結和發現，使得所選架構能夠最大程度地滿足系統需求。
總之，經典的應用系統結構能夠適用於絕大多數的系統開發，它有著最大的優點，就是簡單。然而，它不適應於基於領域驅動設計的專案開發，如果你非要在這樣的架構下實踐領域驅動，那必定是失敗的。
二、cqrs與事件溯源
cqrs與事件溯源有著相輔相成的關係。cqrs允許事件溯源作為領域的資料儲存機制。然而，使用事件溯源的乙個最大的缺點是，你無法向你的系統提出類似「請告訴我所有名字為greg的使用者」這樣的問題，這是由於事件溯源無法提供物件的當前狀態而引起的。cqrs唯一支援的查詢就是：getbyid - 通過id來獲得某個聚合。下圖為基於cqrs的應用系統結構，可以與上圖的經典結構作乙個對比。
對比兩種不同風格的系統架構，我們發現，兩者在客戶端（client）所需要投入的工作量大體上是相同的，因為兩種不同架構下的客戶端所做的操作大體相同：從系統獲得dto，將dto轉換為view model並顯示在ui上，接收使用者輸入，產生命令，然後通知應用系統做相應的操作。在查詢功能的實現上，這兩種系統架構所花費的成本也大體相同：在經典的應用系統結構中，查詢是建立在領域模型上的，而在cqrs結構的應用系統中，查詢則是另外一件事情：它由乙個簡單的讀取訪問層（thin read layer）提供，而這個讀取訪問層會直接將資料對映在dto上。通過對「命令與查詢職責分離」的討論，實現乙個簡單的讀取訪問層不會花費更大的成本，相反，在很多情況下會節省成本開支。
從以上幾點考慮，這兩種不同風格的系統架構所要完成的工作量幾乎是等同的，並不存在額外的工作量，也不存在更少的工作量。這是兩件完全不同的工作。在建模的時候，基於cqrs架構風格的應用系統似乎有一些額外的工作要做，因為你需要定義一系列的事件物件，同時還要編寫事件處理器；但這種工作量相對而言還是比較小的，它有效地降低了甚至避免了「阻抗失衡」效應。總而言之，事實上在大多數情況下，基於cqrs與事件溯源的應用系統更節約成本，而且更加高效。
三、簡單總結
仍然不要因為感覺cqrs看上去更「先進」，就去生搬硬套，這只能給你帶來失敗的教訓。還是要根據專案的實際情況對整個系統的架構與技術選型作出準確的判斷，這也是架構師的主要職責所在。雖然我的部落格中大部分內容都在討論領域驅動設計與cqrs，但這並不表示我會去抵制經典的架構風格，我也同樣在經典的應用系統結構上不斷地學習和思考，我只是希望能夠通過部落格這麼一種東西，來整理一些新鮮的事物，同時也幫助軟體設計與架構的愛好者們開拓視野，豐富知識。
經典的應用系統結構 CQRS與事件溯源
有不少仍然對cqrs與事件溯源 event sourcing 不是很了解，對經典的應用系統架構與cqrs架構之間的差別沒有乙個大概的認識。本文基本上摘自greg young的cqrs documents一文 由daxnet本人翻譯並做了簡要的注釋 希望能夠對應用系統架構的愛好者有所幫助。單擊此處 一...
經典資料結構系列之 佇列的應用
1 前言 資料結構，是計算機程式設計中對資料儲存最基本的操作，不同的資料結構適用不同的業務場景。如今大部分情況都是呼叫開發api封裝好的類庫，直接呼叫，幾乎不需要程式設計師再去深究其中背後實現的邏輯，大大簡化和減低了對程式設計師的要求。正是這種，知其然而不知其所以然，導致很多程式設計師缺乏對於底層結...
資料結構與演算法的那些事
先佔坑，再補充。常用演算法 1 排序 快排 歸併排序 插入排序 希爾排序 桶排序 2 分治演算法 divide and conquer 回溯演算法，貪婪演算法，動態規劃 dp 3 二分查詢 binary search 演算法目標 待排序陣列s 排序後 從小到大遞增陣列s 1 快排 quick sor...