事件源:处理事件架构更改

这是我在过去两年中一直在做的研究主题。 我们发现了5种可用于处理模式演化的技术:

1. 版本化事件:从不更改现有事件,始终引入新事件。
2. 弱模式:优雅地处理缺少的属性或多余的属性。
3. Upcasters:在应用程序必须处理事件之前,在运行时转换事件。
4. 就地改造:只需在商店中更改您需要更改的内容。
5. 复制转换:将整个门店复制到新门店。

我们的论文《事件来源的黑暗面》对此进行了总结( https://www.movereem.nl/files/2017SANER-eventsourcing.pdf )

我们还研究了周边地区:

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

最后一部分尚未公开。但你可以在这里找到我昨天在DDDEurope的演讲幻灯片: https://speakerdeck.com/overeemm/dddeurope-2018-event-sourcing-after-launch

关于如何处理这种情况有什么想法吗?

你 设计 为了它。在确定事件模式时,您将向后兼容性作为首要考虑事项,并且您可以尽早做到这一点,以便以后的更改很容易。

看见 Versioning in an Event Sourced System ,作者:Greg Young。

基本理念:你 从不 改变模式元素的语义。您可以通过添加新的可选元素来扩展架构,也可以拒绝使用可选元素。

当这还不够时:创建一个设计更好的新模式,然后将数据迁移到新模式。

您认为如何使用模式。组织?

我认为那里的模式标识符是一个很好的起点,它们确实提供了与域无关组件共享消息的一些细节的可能性。例如, http://schema.org/telephone 是与通用表示引擎通信的一种很好的方式,其中包含的数据适合拨号。

所以,无论如何,在设计模式时要考虑到这些类型,并尽可能地与它们保持一致。

但当您出现分歧时,请为您的模式提供一个新的标识符。

如果我需要更改事件模式(事件类型),添加或删除属性,或者更改属性的语义,该怎么办?

Use Avro! 它有 a well defined evolution process 用于何时可以添加、修改和删除字段。您可以将其视为JSON的更紧凑版本,它支持所有主要编程语言。

你可以把它和汇合平台的 Avro Schema Registry 这将允许您获得数据模式的真实性和验证来源。此外,您还可以使用Kafka Avro SerDes管理主题中的Kafka消息模式。

有什么办法来处理这种情况吗?

简单的回答是采用事件版本控制和特定的迁移过程。请记住,这是两个不同的问题,尽管它们是相关的。

答案越长越好 the following article .

希望有帮助,干杯