事件溯源：处理事件模式更改

Question

作为一个基于事件溯源架构的软件项目发展，事件模式（或事件类型）是最有可能随着时间改变的事物之一。

事件溯源架构提供的好处之一是它能够“回放所有事件”，并从旧事件中构建当前状态。

如果我需要更改事件模式（事件类型），通过添加或删除属性，或更改属性的语义，那该怎么办呢？当前服务实现将无法处理旧事件，因为它们使用旧模式（它们不包含属性，或者语义已经改变）。

对于如何处理这种情况，有什么想法吗？

- Jordi

Answer 1

这是我过去两年一直在研究的主题。我们发现了 5 种技术，可以用来处理架构演变：

1. 版本化事件：永远不要更改现有事件，而是始终引入新事件。
2. 弱架构：优雅地处理缺少属性或多余属性。
3. Upcaster：在应用程序必须处理事件之前，在运行时转换事件。
4. 原地转换：只需更改存储中需要更改的内容。
5. 复制转换：将整个存储库复制到新存储库中。

这些内容都总结在我们的论文 "The Dark Side of Event Sourcing" 中（https://www.movereem.nl/files/2017SANER-eventsourcing.pdf）。

我们还研究了周边领域：

• 修剪事件存储以保持大小可维护。
• 如何使读模型保持同步。
• DDD 如何帮助您防止架构演变。

最后一个部分目前还没有发布。但是您可以在此处找到我昨天在 DDDEurope 上发表的演讲幻灯片：https://speakerdeck.com/overeemm/dddeurope-2018-event-sourcing-after-launch

- Michiel Overeem

---

你觉得使用schema.org怎么样？ - Jordi

以前从未见过。看起来很有趣，但就个人而言，我只会将其用作灵感。我不想将我的产品与该模式对齐，因为它可能比必要的更加通用。 - Michiel Overeem

您可以扩展和修改类型。这已经是编写超媒体REST服务以在客户端和服务之间共享词汇表的常见资源... - Jordi

听起来很有趣，但链接已经失效了。 - pagliuca

@pagliuca 我修复了链接。 - Michiel Overeem

在这里找到了这个讲座 https://www.youtube.com/watch?v=JzWJI8kW2kc - Chris

Answer 2

有没有关于如何处理这种情况的想法？

你需要为此进行设计。当你在确定事件模式时，要将向后兼容性作为一项首要考虑，并在早期正确处理它，以便以后更改变得容易。

请参阅Greg Young的“事件溯源系统中的版本控制”。

基本思想是：你永远不会改变模式元素的语义。可以通过添加新的可选元素来扩展模式，并且可以弃用可选元素。

当这不足以解决问题时：你需要创建一个更好的设计的新模式，并将数据迁移到新模式。

您对使用schema.org有什么看法？

我认为那里的模式标识符是一个很好的起点，它们确实打开了与领域无关组件共享消息细节的可能性。例如，http://schema.org/telephone是向通用演示引擎传达所包含数据适合拨号的绝佳方式。

因此，请务必根据这些类型设计模式，并尽可能与它们保持一致。

但是，当您分歧时，请为模式提供新的标识符。

- VoiceOfUnreason

---

你认为使用schema.org怎么样？ - Jordi

Answer 3

如果我需要更改事件模式（事件类型），添加或删除属性，或更改属性的语义，怎么办？

使用 Avro！它有一个明确定义的演进过程，可以添加、修改和删除字段。您可以将其视为 JSON 的更紧凑版本，并支持所有主要编程语言。

您可以将其与 Confluent 平台的 Avro Schema Registry 配对使用，这将允许您拥有数据模式的真实来源和验证。此外，您还可以使用 Kafka Avro SerDes 来管理主题内 Kafka 消息模式。（原文链接）（原文链接）（原文链接）

- OneCricketeer

Answer 4

有没有关于如何处理这种情况的想法？

简单来说，可以采用事件版本控制和特定的迁移过程。请记住，尽管相关，但这是两个不同的问题。

更详细的答案在以下文章中。

希望对你有所帮助，祝好！

- Val