基于事件的系统中的消息格式

时间:2018-08-23 03:22:19

标签: messaging event-sourcing

我正在尝试了解有关定义消息的最佳实践,并且我有一些高级问题。

  1. 似乎我们所有的消费者都需要消息的不同方面。这是否意味着消息格式最终只是每个分布式系统所需的一切的结合?
  2. 在不了解所有消费者的情况下,我如何知道要在邮件中添加什么内容?
  3. 是否有最佳实践来帮助确定我是否需要与表格看起来更接近的消息以及更高级别的消息?好像每当我定义一条消息时,它实际上就与我的数据库模式紧密相关。

2 个答案:

答案 0 :(得分:2)

格雷格·杨(Greg Young)的书Versioning in an Event Sourced System对我发掘信息有很大帮助。

  

似乎我们所有的消费者都需要消息的不同方面。这是否意味着消息格式最终只是每个分布式系统所需的一切的结合?

这通常意味着更精细的消息,而订户则对他们查看的消息有更多的区分。

  

在不了解所有消费者的情况下,我如何知道要在邮件中添加什么内容?

尤其是当您不确定要在消息中添加什么内容时,请专注于设计可以安全演化的架构。

  

是否有最佳实践来帮助确定我是否需要与表格看起来相近的消息以及更高级别的消息?似乎每当我定义一条消息时,它实际上就与我的数据库模式紧密相关。

这并非完全是巧合。如果您斜视一下并施加一些想象力,您可能会注意到事件是从一个系统到另一个系统的消息,而持久性是从系统的旧版本到现在的消息。

因此相似之处并没有完全使人震惊。

要小心的一个原因是,由于单个服务是唯一的客户端,因此它可以轻松更改其持久表示。但是,如果需要更新发布者和所有订阅者,则在服务之间更改消息需要格外小心。与单个部署单元中使用的消息相比,跨部署边界的消息通常需要更稳定的架构。

答案 1 :(得分:1)

在事件来源中,域事件将保留,而不是整个状态。因此,域事件包含重构正确状态所需的所有信息。这意味着您将域事件设计为清楚,完整和正确地表达已发生的事实。

事件中最安全的事情也只是重建状态所必需的,而仅此而已。如果您正确地设计了事件(根据域),那么所有订阅者都可以(从域的角度)投影任何有效的可能状态,最有可能的是订阅多个事件流。事件越简单,就需要订阅更多的流,但这没关系。

相关问题