事件採購和驗證上寫

Question

還是蠻年輕的ES和CQRS，據我所知，他們密切相關的數據的最終一致性。

當我們在寫入商店之前應該進行驗證，比如檢查電子郵件地址是否已經被現有用戶使用，最終一致性可能會有問題。以一致的方式做到這一點的唯一方法是停止接受新事件，根據我們的觀點完成剩餘事件的處理，然後查詢視圖。我們顯然不想走得那麼遠，Greg Young實際上是recommends，以接受最終的一致性並處理（罕見的）我們違反約束的情況。

推動這種方法達到極限，我的理解是，這意味着，例如，在開發Web API時，對每個請求做出「OK」響應，因爲在請求時不可能驗證它...我在正確的軌道上，還是在這裏錯過了什麼？

Answer 1

正如我在上面的評論暗示，a RESTful API can return 202 Accepted。

這提供了一種客戶端輪詢狀態更新的方法，如果這是必要的。

客戶可以監視器的狀態，如果這是可取的，但或者，它也可以簡單地消防和忘記，假設如果它得到任何排序200 -range響應，該命令將最終應用。如果您有可以傳播錯誤的替代渠道，這可能是一個很好的選擇。例如，如果您知道哪個用戶提交了該命令，並且擁有該用戶的電子郵件地址，則可以在應用該命令失敗的情況下發送電子郵件。

CQRS體系結構的要點之一是系統的邊緣在接受它之前應該盡其所能來驗證命令的正確性。基於系統的已知狀態（由查詢方暴露），系統可以做出強烈的努力來驗證給定命令是否可接受。如果這樣做，那麼如果接受Command，則唯一的永久性錯誤是併發衝突。根據系統接近一致狀態的速度，這種併發衝突可能很少，例如，向用戶發送電子郵件是一種適當的錯誤處理策略。