何时使用事件存储技术？

Question

我不太确定我是否理解了事件存储(Eventstore)的含义，我认为它是一种领域对象的“事务日志”。它的优点/缺点是什么？何时使用以及何时不应使用它？

编辑:

因为我可能要求过多了，如果有一个简单的情境来说明何时使用事件存储，何时不使用，我会很高兴。换句话说：能否用几个句子描述这两种情况，还是我需要读5本书才能理解它？

- Bernhard Kircher

---

我发现这个很有用：https://chriskiehl.com/article/event-sourcing-is-hard - Jonas Tuemand Møller

Answer 1

是的，事件溯源就像是你的域对象的事务日志，而事务日志是所有数据的权威来源。您可能有其他以易于查询为设计目的的数据副本，但它们只是可以随时被删除和重建的副本。事务日志是唯一的真实来源。

我同意Craig的看法，因为答案非常依赖于上下文，但是这里是一份简短的原因列表，说明为什么您可能考虑使用事件存储：

- 您关心对数据进行复杂的历史分析。例如，将来有人可能会问您：“有多少客户将物品放入购物车，然后将其取出，但在我们给他们发送优惠券之后回来购买了？”此类BI问题有无限的供应，您无法提前预测所有问题。如果捕获系统中的所有事件，则可以重构任何未来问题的答案。 - 同样，您关心审计并能够毫无疑问地证明谁在何时更改了哪些数据以及原因。您的事件存储是您的审计日志。 - 您关心拥有高度可扩展的系统。由于事件存储的写模型是追加方式，因此它非常适合高容量应用程序。由于它不是固有的关系型，因此通常可以轻松分区。

另一方面，有一些不使用它的好理由：

- 您没有上述任何需求。 - 您不想处理必须构建调试工具才能轻松查看和修改事件存储中数据的麻烦。 - 您正在构建一个短期项目，您不希望它存在太长时间，因此不希望将大量架构工作投入其中。

你还没准备好同时学习CQRS、DDD和EDA以及事件溯源。这些想法并不是事件溯源技术所必需的，但它们常常相互交织，只有当你完全改变思维范式并将它们一起使用时才会发现真正的价值。事件溯源是一系列技术中的一部分，这些技术共同代表了一种与软件架构有很大不同的思考方式，可能令人生畏。

- Eric Lee

---

谢谢你的回答，正是我所需要的（一些关于使用事件存储的“简单”示例）。 - Bernhard Kircher

Answer 2

这是一个在stackoverflow上提出的很多要求的问题。你的问题中缺少的一点是它有哪些缺点？无论如何，与其在这里回答，我想为您提供一些视频链接。在回答这个问题之前需要设置很多上下文才能理解。

Greg Young： 这里有一个约2小时的视频here，提供了您在问题中所问的所有内容的概述。 还有一个约6小时的在线课程here。

Udi Dahan： 这里有一个1小时的视频here，可以给出什么时候使用这些技术的视角。

邮件列表： 这里有一个群组here，您可以在此提出所有问题，并围绕该主题进行愉快的讨论。

希望这对你有所帮助。你的问题涉及的内容太多了，我认为简短的解释可能会误导人们，因此不建议这样做。

---

更新：我认为你不需要阅读5本书甚至观看下面的视频。我认为这样做很值得你的时间，但并非必需。你问题的问题在于，“简单”的场景通常不需要事件溯源。大多数应用程序将主要是CRUD和数据驱动的。也许这就是你问题的答案。如果你的系统中没有太多的“行为”，那么你就不需要它。如果有很多行为，那么你可能需要它。

- Craig Wilson

---

谢谢你的回答，链接很有用（虽然我认为我已经知道大部分）。刚刚看到了你回答中的更新 - 这更有用。我赞同了你的回答，但我认为Eric Lee的回答更适合我的问题。 - Bernhard Kircher