cqrs - J Oliver EventStore V2.0 问题

Question

我正在着手实现一个使用 CQRS 的项目，并打算使用 J Oliver EventStore V2.0 作为我的事件持久化引擎。

1) 在文档中，ExampleUsage.cs 在“BuildSerializer”中使用了 3 个序列化程序。我想这只是为了展示反序列化过程的灵 active ？

2) 在“失败后重新启动”的情况下，某些事件未被分派(dispatch)，我相信我需要启动代码来调用 GetUndispatchedCommits() 然后分派(dispatch)它们，对吗？

3) 同样，在“ExampleUseage.cs”中，如果“TakeSnapshot”将第三个事件添加到事件存储中，然后“LoadFromSnapShotForward”不仅检索最新的快照，还检索快照后的事件以进行模拟，这将很有用聚合体的重建。

4) 我没有看到保留旧快照的用途。您能提供一个使用案例吗？

5) 如果我有一项服务正在处理命令的接收和事件的生成，那么建议的策略是跟踪自给定聚合的最后一个快照以来的事件数量。我当然不想过于频繁地调用“GetStreamsToSnapshot”。

6) 在 SqlPersistence.SqlDialects 命名空间中，sql 语句名称是“GetStreamsRequiringSnaphots”而不是“GetStreamsRequiringSnapShots”

Answer 1

1) 有一些“基础”序列化器——例如二进制、JSON 和 BSON 序列化器。示例中的另外两个——GZip/Compression 和 Encryption 序列化程序是包装序列化程序，仅用于修改已序列化为字节流的内容。例如，我只是展示了灵 active 。如果您不想，则不必加密。事实上，我有一些运行生产的东西使用简单的 JSON，这使得调试非常容易，因为一切都是文本。

2) SynchronousDispatcher 和 AsychronousDispatcher 实现都配置为查询和查找任何未分派(dispatch)的提交。您不必做任何特别的事情。

3) Greg Young 谈到他过去是如何将他的快照与主事件流“内联”的，但是在高性能系统中出现了许多乐观并发和竞争条件。因此，他决定将它们移到“带外”。出于许多相同的原因，我遵循了这个决定。

此外，当您的 SLA 极低时，快照确实是一个性能考虑因素。如果您有一个包含几千个事件的流，并且您的 SLA 不低，为什么不采取最小的性能影响，而不是在您的系统中增加额外的复杂性。换句话说，快照是“辅助”概念。它们位于 EventStore API 中，但它们是一个可选概念，在某些用例中应予以考虑。

4) 假设您有一个包含数千万个事件的聚合，并且您想从最近的快照之前运行一个“假设”场景。从另一个快照向前移动要便宜得多。快照作为次要概念的真正好处是，如果您想删除较旧的快照，您可以，而且它根本不会影响您的系统。

5) IPersistStreams 的每个实现中都有一个名为 GetStreamsRequiringSnapshots 的方法。例如，您提供 50 的阈值，它会查找自上次快照以来具有 50 个或更多事件的所有流。这可以(而且可能应该)与您的正常处理异步完成。

6) “快照”是该词的正确大小写。很像“website”曾经是“Web site”，但由于常见用法，它变成了“website”。