事件存储中的事件模型或模式答案

【问题标题】：Event model or schema in event store事件存储中的事件模型或模式
【发布时间】：2017-07-15 07:18:14
【问题描述】：

事件存储（事件溯源）中的事件通常以带有版本的序列化格式持久化，以表示事件类型的模型或架构中的更改。我无法找到显示实际事件的实际模型或架构的良好文档（如果使用 RDBMS，通常是事件存储架构中的 data 表），但我理解理想情况下它应该是通用的。

事件中应该存在哪些最基本的字段/属性？

我曾考虑使用 json-api 作为我的事件的规范，但也许这太“沉重”了。我看到的好处是灵活性和成熟度。

我是不是走上了“错误的道路”？

任何定义明确的示例将不胜感激。

【问题讨论】：

您能否添加一个诸如 .net 之类的标签，除非您故意想要一个通用的答案？ event-store 也表示 neventstore - 如果您是指 Greg Young 的 GES，则有 get-event-store
事件存储和事件架构不依赖于 .net 或 neventstore。
我非常清楚这一点。关键是，无论好坏，标记事件存储并不意味着您认为它的含义 - 它意味着一个 .NET 存储 [通常在 SQL DB 中使用]。我对你想要一个通用的答案也没有意见

【解决方案1】：

我曾考虑使用 json-api 作为我的事件的规范，但也许这太“沉重”了。我看到的好处是灵活性和成熟度。

我是不是走上了“错误的道路”？

不要忽视向前和向后兼容性。

您应该计划在event versioning 上查看 Greg Young 的书；它不会直接回答您的问题，但确实涵盖了很多关于解释事件的基础知识。

简短的回答：几乎所有内容都是可选的，因为您需要以后能够更改它。

您还应该查看 Hohpe 的企业集成模式，尤其是他在 messaging 上的工作，其中详细介绍了您可能关心的许多案例。

de Graauw 的 Nobody Needs Reliable Messaging 帮助我理解了一个重点。

总结一下：如果可靠性在业务层面很重要，那么就在业务层面进行。

因此，虽然您可能想做一些有趣的元数据跟踪，但域模型实际上只关注数据；这往往是特定于您的域的。

您也很高兴您在产生它们的服务中使用的事件表示可能与它与其他服务共享的表示不匹配，特别是可能不是相同的消息得到广播。

我进行了一项练习，试图找出订阅者查看事件以了解它是否关心所需的最少信息量。我的答案是一个 id（我以前见过这个特定事件吗？），一个告诉你消息语义的标记（这是我关心的东西吗？），以及一个位置 (URI)，如果它可以得到更丰富的表示是我关心的事情。

但在域之外 - 例如，当您将系统作为一个整体查看时，试图找出正在发生的事情，具有相关标识符和因果标识符、时间戳、源位置的签名等等对存储在元数据中的一致位置会有很大帮助。

【讨论】：

【解决方案2】：

只需使用映射到 Json 的基本类型进行建模，就可以像编写 API 一样编写代码。

如果您使用太多工具，您可能会花费大量时间来生成过于复杂的模型 - Apache Thrift 和/或 Protocol Buffers（或派生的东西）之类的东西会为您提供各种 IDL 机制来产生偶然的复杂性与。

在 .NET 领域和许多其他平台中，如果为类型命名，则可以从类型中进行各种投影

就个人而言，我在 F# 中使用记录和 DU 作为设计和表示工具

【讨论】：