我正在着手使用CQRS实施项目，并打算使用J Oliver EventStore V2.0作为事件的持久性引擎。
1）在文档中，ExampleUsage.cs在“BuildSerializer”中使用了3个序列化程序。我认为这只是为了显示反序列化过程的灵活性？
2）在“失败后重启”的情况下，没有调度某些事件我相信我需要启动代码来调用GetUndispatchedCommits（）然后调度它们，对吗？
3）同样，在“ExampleUseage.cs”中，如果“TakeSnapshot”将第三个事件添加到事件库，然后“LoadFromSnapShotForward”不仅会检索最新的快照，还会检索发布快照的事件以进行模拟，这将非常有用。重建聚合。
4）我没有看到使用保留较旧的快照。你能给出一个有用的用例吗？
5）如果我有一个处理命令接收和事件生成的服务，那么建议的策略是跟踪自给定聚合的上一个快照以来的事件数量。我当然不想经常调用“GetStreamsToSnapshot”。
6）在SqlPersistence.SqlDialects命名空间中，sql语句名称为“GetStreamsRequiringSnaphots”而不是“GetStreamsRequiringSnapShots”
答案 0 :(得分：3)
1）有一些“基本”序列化器 - 例如二进制，JSON和BSON序列化器。示例中的另外两个 - GZip / Compression和Encryption序列化程序包装序列化程序，仅用于修改已经序列化为字节流的内容。例如，我只是表现出灵活性。如果您不想加密，则无需加密。事实上，我有一些运行生产的东西，使用简单的JSON，这使得调试非常简单，因为一切都是文本。
2）SynchronousDispatcher和AsychronousDispatcher实现都配置为查询和查找任何未分配的提交。你不应该做任何特别的事。
3）Greg Young谈到他过去如何使用主要事件流“内联”他的快照，但是在高性能系统中出现了许多乐观的并发和竞争条件。因此，他决定将它们“带出”。出于许多相同的原因，我遵循了这个决定。此外，当您拥有极低的SLA时，快照确实是一种性能考虑因素。如果您有一个包含几千个事件的流并且您没有低SLA，那么为什么不采用最小的性能命中而不是在系统中增加额外的复杂性。换句话说，快照是“辅助”概念。它们位于EventStore API中，但它们是一个可选概念，应该考虑用于某些用例。
4）假设您有一个包含数千万个事件的聚合，并且您希望在最近的快照之前运行“假设”场景。从另一个快照向前走的便宜得多。关于快照作为次要概念的一个非常好的事情是，如果您想删除较旧的快照，那么它根本不会影响您的系统。
5）IPersistStreams的每个实现中都有一个名为GetStreamsRequiringSnapshots的方法。您提供的阈值为50，例如，它发现自上次快照以来所有流都有50个或更多事件。这可以（也可能应该）与正常处理异步完成。
6）“快照”是该单词的正确大小写。很像“网站”曾经是“网站”，但由于常见用法，它变成了“网站”。