J Oliver EventStore V2.0問題

Question

我正在着手使用CQRS實施一個項目，並打算使用J Oliver EventStore V2.0作爲事件的持久性引擎。

1）在文檔中，ExampleUsage.cs在「BuildSerializer」中使用3個序列化器。我認爲這只是爲了展示反序列化過程的靈活性？

2）在「重新啓動後失敗」的情況下，一些事件沒有分派我相信我需要啓動代碼調用GetUndispatchedCommits（）然後發送它們，正確嗎？ 3）同樣，在「ExampleUseage.cs」中，如果「TakeSnapshot」將第三個事件添加到事件存儲區，然後「LoadFromSnapShotForward」不僅檢索最近的快照，而且檢索到快照後的事件模擬聚合的重建。

4）我沒有看到使用保留舊的快照。你可以給一個用例，他們會有用嗎？如果我有一個處理命令接收和事件生成的服務，那麼建議的策略是跟蹤自給定聚合上次快照以來的事件數量。我當然不想太頻繁地調用「GetStreamsToSnapshot」。

6）在SqlPersistence.SqlDialects命名空間中的SQL語句的名稱是 「GetStreamsRequiringSnaphots」，而不是 「GetStreamsRequiringSnapShots」

Answer 1

1）有幾個 「基地」 串行 - 如二進制，JSON和BSON序列化。示例中的另外兩個 - GZip/Compression和Encryption序列化器封裝了序列化器，僅用於修改已經序列化爲字節流的內容。例如，我只是表現出靈活性。如果你不想要，你不需要加密。事實上，我有一些使用簡單JSON的產品正在運行，這使得調試變得非常簡單，因爲一切都是文本。

2）SynchronousDispatcher和AsychronousDispatcher實現都配置爲查詢和查找任何未分派的提交。你不應該做任何特別的事情。 3）Greg Young談到他如何用主事件流「嵌入」他的快照，但在高性能系統中出現了一些樂觀的併發和競爭條件。因此他決定將它們移出「帶外」。出於許多相同的原因，我遵循了這個決定。

此外，當SLA極低時，快照確實是性能考慮因素。如果您有一個包含幾千個事件的流，並且您沒有較低的SLA，那麼爲什麼不只是將性能降至最低，而不是爲系統增加額外的複雜性。換句話說，快照是「輔助」概念。它們在EventStore API中，但是它們是一個可選概念，應該在某些使用情況下考慮它。

4）假設您有一個包含數千萬事件的聚合，並且您想在最近的快照之前運行「假設」情形。從另一個快照向前轉移要便宜很多。關於快照是一個次要概念的真正好處是，如果您想刪除較舊的快照，您可以完全不會影響您的系統。

5）每個IPersistStream實現中都有一個名爲GetStreamsRequiringSnapshots的方法。例如，您提供了一個50的閾值，例如，它會查找自上次快照以來具有50個或更多事件的所有流。這可以（也可能應該）與正常處理異步完成。

6）「快照」是該單詞的正確包裝。很像「網站」曾經是「網站」，但由於常見的用法，它成爲「網站」。