这是我在过去两年所做研究的主题。我们发现了5种可用于处理模式演化的技术：
版本化事件：从不更改现有事件，总是引入新事件。
弱模式：优雅地处理缺少的属性或多余的属性。
upcasters：在应用程序必须处理事件之前，在运行时转换事件。
就地改造：只需在商店里改变你需要改变的东西。
复制转换：将你的整个商店复制到一个新的商店。
我们的论文“事件来源的黑暗面”对此进行了总结(https://www.movereem.nl/files/2017saner-eventsourcing.pdf)
我们还调查了周边地区：
修剪事件存储以保持大小可维护。
如何保持你的阅读模型同步。
ddd如何帮助您防止模式演化。
最后一部分尚未公开。但你可以在这里找到我昨天在DDD的演讲幻灯片：https://speakerdeck.com/overeemm/dddeurope-2018-event-sourcing-after-launch

你对如何处理这种情况有什么想法吗？
你为它设计。在弄清楚事件模式时，首先要考虑向后兼容性，而且要尽早做到这一点，这样以后的更改就很容易了。
请参阅greg young的《事件源系统中的版本控制》。
基本思想是：永远不会改变模式元素的语义。可以通过添加新的可选元素来扩展架构，也可以不推荐可选元素。
当这还不够时：创建一个设计更好的新模式，然后将数据迁移到新模式。
你觉得使用schema.org怎么样？
我认为那里的模式标识符是一个很好的起点，它们确实为与领域无关的组件共享消息的一些细节提供了可能性。例如， http://schema.org/telephone 是与通用表示引擎进行通信的一种很好的方式，说明所包含的数据适合拨号。
因此，无论如何，在设计模式时要考虑到这些类型，并尽可能地与它们保持一致。
但是，当您出现分歧时，请为您的模式提供一个新的标识符。

如果我需要更改事件模式（事件类型），添加或删除属性，或者更改属性的语义，该怎么办？
使用avro！对于何时可以添加、修改和删除字段，它有一个定义良好的演化过程。您可以把它看作是一个更紧凑的json版本，它支持所有主要的编程语言。
您可以将其与confluent平台的avro模式注册表配对，这将允许您获得数据模式的真实性和有效性来源。另外，您还可以使用kafka avro serdes来管理主题中的kafka消息模式。