我非常喜欢使用/了解EventStore或get-event-store，因为这里可能已知。
我已经使用了有关客户，预测和订阅的文档，并且已准备好开始使用某些内部项目。
我能够完成的一件事 - 是否有一套指南/建议来描述事件元数据和数据之间的区别？我知道名义上的差异;活动数据是＆＃39;核心＆＃39;到域，元数据用于描述，但它变得相当精神。
我想知道是否有关于实施（查询等）的硬性规则。
任何指导都非常感激！
答案 0 :(得分：2)
我将与您分享我的经验，这可能有所帮助。我一直在玩akka-persistence，akka-persistence-eventstore和eventstore。 akka-persistence以二进制格式存储它的事件包装器PersistentRepr。我想用JSON中的这些数据，以便我可以：
您可以为akka-persistence-eventstore实现自己的序列化来执行此操作，但它最终只是存储将事件嵌入到payload属性中的包装器。其他属性都是特定的akka-persistence。 akka-persistence-eventstore的作者给了我一些很好的建议，让序列化器将有效负载存储为数据，其余的作为MetaData。这样我的事件现在只是业务数据，元数据帮助了首先把它放在那里的技术。我的预测现在不需要解析元数据以获得有效载荷。
答案 1 :(得分：0)
从Szymon Kulec的博客文章“ Enriching your events with important metadata”（着重强调）中无耻地复制（和释义）：
但是，哪些信息可用于存储在元数据中，尽管该信息未在其中捕获，但还是值得存储的信息 模型的创建？
1。审核数据
- 谁 –只需存储操作调用者的用户ID
- 何时？ –动作和事件的时间戳
- 为什么？ –演员的序列化意图/动作
2。事件版本控制
事件源处理动作的效果。一种行为 在状态下执行会导致根据当前状态执行操作 实施。等待。当前执行？是的 汇总的实现可能会更改，这可能是因为 错误修复或引入新功能。 如果这不是很好 版本，例如提交ID（对于Gitter而言为SHA1）或语义版本 也可以与事件一起存储吗？想象一下，您发布了一个 损坏的版本，您的企业在修复错误之前售出了100张票。 很高兴能够根据 实施失败。有了这些知识，您可以轻松补偿 实施失败的交易。
3。文件实施细节
引入金丝雀版本，功能切换和 用户的A / B测试。借助自动部署和少量代码 增强所有提到的方法都是可行的 项目委员会。如果您考虑切换或其他实现 在同一时刻共存，仅存储版本可能是 不够。如何添加信息应用了哪些功能 采取行动？只需创建一组简单的功能即可启用或映射 功能状态，并将其添加到事件中。有这个和 命令，很容易重复该过程。另外，很容易 进行A / B实验。只需使用A运行扫描事件 启用，另一个启用B。
4。 2.和3.的优化组合。
如果您认为这太多了，请为 版本x功能。它没有那么大，可以在许多情况下重复 用户，因此您可以轻松地优化将集合存储在其他位置 参考键。您可以序列化此映射并计算SHA1， 映射中的值（表也可以）并使用标识符来 将它们放在事件中。有很多选项可以转移负载 查询（查找）或存储（将所有内容存储为 命名元数据）。
总结
如果您创建事件源架构，请考虑添加 时间维度（版本）以及对 元数据。一旦有了它，就可以更轻松地推断出 事件的来源，并引入补偿等工具。 不会有太多数据这样的事情吗？