事件存储（事件源）中的事件通常以序列化格式保留，其中的版本表示事件类型的模型或模式中的更改。我无法找到显示实际事件的实际模型或模式的良好文档（如果使用RDBMS，通常在事件存储模式中data表），但理解它应该是通用的。
活动中应该存在哪些最基本的字段/属性？
我已经考虑过使用json-api作为我的活动的规范，但也许这太“重”了。我看到的好处是灵活性和成熟度。
我是否正走向“错误的道路”？
非常感谢任何定义良好的例子。
答案 0 :(得分：3)
我已经考虑过使用json-api作为我的活动的规范，但也许这太“重”了。我看到的好处是灵活性和成熟度。
我是否正走向“错误的道路”？
不要忽视向前和向后兼容性。
您应该计划在event versioning上查看Greg Young的书;它没有直接回答你的问题，但它确实涵盖了很多关于解释事件的基础知识。
简短的回答：几乎所有东西都是可选的，因为你需要以后能够改变它。
您还应该查看Hohpe的企业集成模式，特别是他对messaging的工作，其中详细介绍了您可能关心的许多案例。
de Graauw的Nobody Needs Reliable Messaging帮助我理解了一个重点。总结一下：如果可靠性对业务级别很重要，请在业务级别进行。
因此，虽然您可能想要进行一些有趣的元数据跟踪，但域模型实际上只会查看数据;而这往往是针对您的域名的。
您也的乐趣在于，您在服务中使用的事件的表示可能与它与其他服务共享的表示不匹配，特别是可能不是相同的消息得到广播。
我进行了一项练习，试图找出订阅者查看事件所需的最少信息量，以了解其是否关心。我的答案是一个id（我之前看过这个特定事件吗？），一个告诉你消息的语义含义的令牌（我关心的是什么？），以及一个位置（URI）来获得更丰富的表示是我关心的事情。
但是在域之外 - 例如，当你整个系统看着试图弄清楚发生了什么时，有相关标识符和因果关系标识符，时间戳，源位置的签名等等存储在元数据中的一致位置可能是一个很大的帮助。
答案 1 :(得分：1)
使用映射到Json的基本类型进行建模，就像对API一样，可以大有帮助。
如果你投入过多的工具，你可能会花费大量的时间来生成过于复杂的模型 - 像Apache Thrift和/或Protocol Buffers（或派生的东西）这样的东西会为你提供各种IDL机制来产生偶然的复杂性用。
在.NET land和许多其他平台中，如果您对类型进行命名空间，则可以从类型
进行各种投影就个人而言，我在F＃中使用记录和DU作为设计和表示工具
types.fs有他们所需要的一切