我們是否真的需要一個具有事件採購和CQRS模式的獨立事件存儲？

Question

假設我們有一種情況，當我們需要實現一些需要檢查對象歷史（事件存儲）的域規則時。例如，我們有一個具有CurrentStatus屬性的Order對象，我們需要檢查Order.CurrentStatus更改歷史記錄。

最有可能你會回答，我需要這方面的知識遷移到域，並引入包含的狀態記錄的集合Order.StatusHistory財產，我不應該查詢事件存儲。我會同意你的意見。

我的問題是事件存儲的需要。

我們寫事件存儲事件具有商業意義（域值），我們不記錄UserMovedMouse事件（大多數情況下）。與OrderStatusChanged事件一樣，Event Domain的大部分事件都有可能出現在域邏輯的某個點上，我們最終得到一個具有事件集合的EventHistory屬性的域對象。

我可以看到圖案單獨事件存儲的值，如CQRS當你有一個只寫事件存儲和多個只讀查詢商店，它給你一些的可擴展性。然而，我需要在代碼中引入這樣的東西。所有像樣的數據庫都支持單個寫入服務器，多個讀取服務器的可擴展性（主從複製）。爲什麼我應該在源代碼級別引入這樣的東西？爲什麼不忘記Web服務和消息總線，並使用在套接字周圍編寫自己的包裝。

我有，因爲它是BE Eric Evans的描述爲「老同學」 DDD很尊重，我看到新一波DDD + SQRC + EventSourcing花樣粒料一些新鮮的和好的想法。然而CQRS的主要思想對我來說是個大問題。我錯過了什麼嗎？

Answer 1

簡而言之：如果不需要事件採購（其增值收益或解決方法有些怪癖），那麼你絕對不應該把它納入你的系統只是爲了它的緣故。

ES只是衆多方法有界範圍內增加CQRS建築風格之一。這不是要求。