使用CQRS讀取端實現方法

Question

我已經轉移到正在積極使用CQRS +事件採購的項目。從乍一看，它是根據所有這些書籍和博客實施的，但最終我意識到實施過程中究竟有什麼不好的地方。

這裏是CQRS架構：

本來我把這張照片從here。

正如我們在圖片中看到的那樣，讀取端從隊列中接收事件，並將其逐個傳遞到不同的投影集合（反規範化器），然後通過AddOrUpdate方法將結果ViewModel保存到DB中。所以我從圖片中瞭解到，denormalizer只能依賴事件本身加上來自read-side db的數據。 例如：

1. 帳戶視圖已存儲在數據庫中。
2. EmailChanged事件到達
3. 我們從DB
4. 讀取帳戶查看電子郵件應用改變它
5. 我們保存的帳戶回DB。

的情況下（計數的一些項目數，說訂單）：

1. OrderCreated事件到達
2. 我們讀它代表NumberOf視圖模型之前已經到達訂單
3. 增量並保存此。

我們在我們的項目中有什麼： 我們將所有這些事件僅用作通知程序，以便在域模型中更改某些內容。因此，我們做什麼：

1. 我們採取域存儲庫，並閱讀所有必要的聚合。這樣做，我們得到他們的最新狀態。
2. 我們只是從頭
3. 保存新創建的對象建立視圖模型對象到數據庫

我們在我們的項目中使用這種方法看起來有點怪我，我不能看到這一切的缺點雖然。如果我們需要重建讀取方，我們添加「活動」denormalizer並且下一次它接收到特定的事件時，它會重新創建新的視圖模型。

如果我們使用書中的方法，我將不得不在我的系統之外有一個獨立的utils邏輯用於重建。我們需要爲這個什麼：

1. 下降讀取端
2. 從頭閱讀從事件存儲中的所有事件
3. 通過他們通過投影

所以我的問題是：
這裏的正確方法是什麼？

Answer 1

我們在項目中使用的方法看起來有點奇怪，我不能 看到它的所有缺點。

一個突出的缺點是，在收到事件後，您必須再次調用相應聚合的存儲庫。這意味着此存儲庫必須直接或作爲服務公開。除了增加的依賴關係外，還有另外的IO。

對於從事件庫重建，您描述的方法是普遍接受的方法。描述的方法here利用專用於重建投影的事件日誌。這可以用來解決性能問題，同時重建。也請看看Scalable and Simple CQRS Views in the Cloud和DDD/CQRS mailing list。