我想知道使用 EventStore (http://geteventstore.com) 与在 MongoDb 中自己实现事件溯源相比有什么优势。
我问的原因是，我们公司有很多人每天都在使用 MongoDb。但它们不适用于事件溯源。虽然他们对这个主题并不完全一无所知，但他们也不打算在任何地方开始实现它。
我即将开始一个非常适合事件溯源的项目。大约有 16 个定义明确的事件，以及大约 7 个定义明确的预测。我说“关于”是因为我知道一旦他们看到产品在使用中，就会有更多的预测和事件的需求。
该方法将首先使用 API，并使用我们组织的其他部分将使用的 REST Api。
虽然我已经阅读了很多关于 Greg Young 定义的事件溯源的信息，但我从未真正实现过事件溯源解决方案。
这是一个绿地项目。没有技术限制，因为我们将把所有东西都公开为 REST 接口(interface)。因此，如果有人有使用 MongoDb 的 EvenStore 或 Event Sourcing 的工作经验，请赐教。
还有一个关于事件溯源的几乎完全不相关的问题: 你有没有直接查询事件存储？或者您是否总是创建新的投影和重播事件来填充这些投影？
最佳答案
免责声明我是 Greg Young(如果你看不懂我的名字 :))
我将回答这个问题，尽管我相信它可能会被删除。这个问题对我来说有点奇怪，但答案相当奇怪。我不会花时间单独回答每个回复，而是会将我的所有评论都放在此回复中。
1) 有一条评论说，我们只在自定义版本的 mono 上运行，这是一个细节，但是......情况并非如此(并且已经超过一年了)。我们正在等待我们为单声道制作的关键补丁(例如 threadpool.c 以击中他们的主人)。这已经发生了。
2) EventStore 是 3-clause BSD 许可的。不知道你怎么能声称我们不是开源的。我们还有一家公司支持它并提供商业支持。
3) 有人提到我们将在 9 月升级到第 3 版。第 1 版在 2 年前发布。版本 2 添加了集群(显然与单节点相比有一些重大更改)。第 3 版添加了大量内容，包括拥有竞争消费者的能力。在这段时间里，实际客户端协议(protocol)几乎没有什么变化(尤其是对于那些使用 HTTP API 的客户端)。
然而，这些建议让我真正感到不安的是，他们似乎不明白他们在比较什么。这大致相当于我说“我应该使用 neo4j 还是 leveldb？”。您可以在 leveldb 之上构建自己的图形数据库，但这将是相当多的工作。
在这种情况下，Mongo 将是 OP 必须自己编写的事件存储上的存储引擎。如果您想拥有最基本的操作，那么在存储引擎之上编写生产质量事件存储是一项不平凡的练习。
我写了 this in response to the mailing list equivalent of this question :
How will you do the following with Mongo?:
Write and read events to/from streams with ordering/optimistic concurrency/etc
Then:
Your projections don't want to read from streams in the same way they were written, projections are normally interested in event types and want all events of type T regardless of stream written to and in proper order.
You probably also want for instance the ability to switch live from pushed event notifications to handling pulled information (eg polling) etc.
如果将 Kafka、datomic 和 Event Store 进行比较会更有意义。
关于mongodb - EventStore 与 MongoDb，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/19467084/