事件存储(事件溯源)中的事件通常以序列化格式保存，其中版本表示事件类型的模型或架构中的更改。我一直无法找到显示实际事件的实际模型或模式的良好文档(如果使用 RDBMS，通常是事件存储模式中的 data 表)但我明白理想情况下它应该是通用的。
事件中应该存在的最基本的字段/属性是什么？
我考虑过使用 json-api 作为我的事件的规范，但也许这太“重”了。我看到的好处是灵 active 和成熟度。
我是在走“错误的道路”吗？
任何明确定义的示例将不胜感激。
最佳答案
I've contemplated using json-api as a specification for my events but perhaps that's too "heavy". The benefits I see are flexibility and maturity.
Am I heading down the "wrong path"?
不要忽视向前和向后的兼容性。
您应该计划在 event versioning 上复习 Greg Young 的书;它没有直接回答您的问题，但确实涵盖了很多有关解释事件的基础知识。
简短回答:几乎所有内容都是可选的，因为您以后需要能够更改它。
您还应该查看 Hohpe 的企业集成模式，尤其是他关于 messaging 的工作，其中详细介绍了很多您可能关心的案例。
de Graauw 的 Nobody Needs Reliable Messaging帮助我理解了一个重要的观点。
To summarize: if reliability is important on the business level, do it on the business level.
因此，尽管您可能想要进行一些有趣的元数据跟踪，但域模型实际上只会查看数据；这往往会特定于您的域。
您还有的乐趣在于，您在产生事件的服务中使用的事件表示可能与它与其他服务共享的表示不匹配，尤其是可能不是同一消息得到广播。
我完成了一个练习，试图找出订阅者查看事件以了解它是否关心所需的最少信息量。我的答案是一个 id(我以前见过这个特定事件吗？)，一个告诉你消息语义的标记(这是我关心的东西吗？)，以及一个位置(URI)以获得更丰富的表示，如果它是我关心的事情。
但在域之外——例如，当您将系统作为一个整体来查看时，试图找出正在发生的事情，具有相关标识符和因果标识符、时间戳、源位置的签名等on 存储在元数据中的一致位置可能会有很大帮助。
关于events - 事件存储中的事件模型或模式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/42438958/