事件驱动架构和事件结构 [英] Event-driven architecture and structure of events

问题描述

我是 EDA 的新手，我已经阅读了很多关于好处的内容，并且可能有兴趣在我的下一个项目中应用它，但仍然没有理解一些东西.

I'm new to EDA and I've read a lot about benefits and would probably be interested to apply it during my next project but still haven't understood something.

引发事件时，哪种模式最适合:

When raising an event, which pattern is the most suited:

1. 将事件命名为CustomerUpdate"并包含有关客户的所有信息(更新与否)
2. 将事件命名为CustomerUpdate"并仅包含真正更新的信息
3. 将事件命名为CustomerUpdate"并包含最少信息(标识符)和/或 URI，以便消费者检索有关此客户的信息.

我问这个问题是因为我们的一些活动可能很繁重而且很频繁.

I ask the question because some of our events could be heavy and frequent.

感谢您的回答和时间.

推荐答案

将事件命名为CustomerUpdate"

Name the event "CustomerUpdate"

首先让我们从您的活动名称开始.事件的目的是描述已经发生的事情.这与命令不同，命令是针对尚未发生的事情发出指令.

First let's start with your event name. The purpose of an event is to describe something which has already happenned. This is different from a command, which is to issue an instruction for something yet to happen.

您的活动名称CustomerUpdate"在这方面听起来很模棱两可，因为它可能描述过去或未来的事情.

Your event name "CustomerUpdate" sounds ambiguous in this respect, as it could be describing something in the past or something in the future.

CustomerUpdated 会更好，但即便如此，Updated 也是另一个模棱两可的术语，在业务环境中是非特定的.为什么在这种情况下更新了客户?是因为他们更改了付款详细信息吗?搬家了?他们是否从白银升级为黄金状态?可以根据需要制作特定的活动.

CustomerUpdated would be better, but even then, Updated is another ambiguous term, and is nonspecific in a business context. Why was the customer updated in this instance? Was it because they changed their payment details? Moved home? Were they upgraded from silver to gold status? Events can be made as specific as needed.

这乍一看似乎是多虑了，但是当您从事件有效负载中删除数据和上下文时，事件命名变得尤为重要，更多地转向瘦事件(来自您的选项 3")问题，我将在下面讨论).

This may seem at first to be overthinking, but event naming becomes especially relevant as you remove data and context from the event payload, moving more toward skinny events (the "option 3" from your question, which I discuss below).

这并不是说在这个粒度级别定义事件总是合适的，只是它是一个在项目早期向您开放的途径，可能会在以后支付红利(或可能淹没您)数以千计的事件类型).

That is not to suggest that it is always appropriate to define events at this level of granularity, only that it is an avenue which is open to you early on in the project which may pay dividends later on (or may swamp you with thousands of event types).

回到您的实际问题，让我们依次考虑您的每个选项:

Going back to your actual question, let's take each of your options in turn:

将事件命名为CustomerUpdate"并包括所有信息(更新与否)关于客户

Name the event "CustomerUpdate" and include all information (updated or not) about the customer

我们称之为模式"Fat 信息.

Let's call this "pattern" the Fat message.

胖消息(​​也称为快照)表示所描述实体在给定时间点的状态，所有事件上下文都存在于有效负载中.它们很有趣，因为消息本身代表了服务和消费者之间的契约.它们可用于在业务领域之间传达状态变化，在这种情况下，消费者最好在消息处理期间提供所有事件上下文.

Fat messages (also called snapshots) represent the state of the described entity at a given point in time with all the event context present in the payload. They are interesting because the message itself represents the contract between service and consumer. They can be used for communicating changes of state between business domains, where it may be preferred that all event context be present during message processing by the consumer.

优点:

• 自我一致 - 无需了解其他系统即可完全使用.
• 易于使用(更新插入).

缺点:

• 脆弱 - 服务和消费者之间的契约与消息本身耦合.
• 如果消息以错误的顺序到达，则很容易用旧数据覆盖当前数据(提示:您可以使用 事件溯源模式)
• 大.

将事件命名为CustomerUpdate"并且仅包含具有以下信息的信息真的更新了

Name the event "CustomerUpdate" and include only information that have really been updated

让我们将此模式称为 Delta 消息.

Let's call this pattern the Delta message.

Delta 在很多方面都类似于胖消息，尽管它们的生成和消费通常更复杂.一个很好的例子是 JSONPatch 标准.

Deltas are similar to fat messages in many ways, though they are generally more complex to generate and consume. A good example here is the JSONPatch standard.

因为它们只是事件实体的部分描述，增量还带有一个内置假设，即消费者对所描述的事件有所了解.出于这个原因，它们可能不太适合发送到业务领域之外，因为在那里事件实体可能并不为人所知.

Because they are only a partial description of the event entity, deltas also come with a built-in assumption that the consumer knows something about the event being described. For this reason they may be less suitable for sending outside a business domain, where the event entity may not be well known.

在共享相同实体模型的系统之间同步数据时，Delta 真的很出色，理想情况下，它可以持久保存在非关系存储(例如，no-sql)中.在这种情况下，可以检索实体，应用增量，然后以最小的努力再次持久化.

Deltas really shine when synchronising data between systems sharing the same entity model, ideally persisted in non-relational storage (eg, no-sql). In this instance an entity can be retrieved, the delta applied, and then persisted again with minimal effort.

优点:

• 小消息
• 在涉及共享实体模型的用例中表现出色
• 便携(如果基于 jsonpatch 等标准，或者在较小程度上基于 diffgram)

缺点:

• 与 Fat 消息类似，假设完全了解数据实体.
• 很容易用旧数据覆盖当前数据.
• 生成和使用的复杂性(特定用例除外)

将事件命名为CustomerUpdate"并包括最少的信息(标识符)和/或让消费者检索信息的 URI关于这位客户.

Name the event "CustomerUpdate" and include minimum information (Identifier) and/or a URI to let the consumer retrieves information about this Customer.

让我们称之为 Skinny 消息.

Let's call this the Skinny message.

瘦消息与您定义的其他消息模式不同，因为服务/消费者契约在消息中不再是明确的，而是暗示消费者稍后将检索事件上下文.这将合约和消息交换解耦，这是一件好事.

Skinny messages are different from the other message patterns you have defined, in that the service/consumer contract is no longer explicit in the message, but implied in that at some later time the consumer will retrieve the event context. This decouples the contract and the message exchange, which is a good thing.

这可能适合也可能不适合事件的跨业务领域通信，具体取决于您的企业是如何设置的.由于事件有效负载非常小(通常是带有一些标头的 ID)，除了事件名称之外，没有其他上下文可供消费者做出处理决策；因此，确保正确命名事件变得更加重要，尤其是在消费者可以通过多种方式处理 CustomerUpdated 消息的情况下.

This may or may not lend itself well to cross-business domain communication of events, depending on how your enterprise is set up. Because the event payload is so small (usually an ID with some headers), there is no context other than the name of the event on which the consumer can base processing decisions; therefore it becomes more important to make sure the event is named appropriately, especially if there are multiple ways a consumer could handle a CustomerUpdated message.

此外，在事件数据中包含实际资源地址可能不是一个好习惯——因为事件是已经发生的事情，事件消息通常是不可变的，因此事件中的任何信息都应该永远真实，以防万一需要重播.在这种情况下，资源地址很容易过时，事件将无法重播.

Additionally it may not be good practice to include an actual resource address in the event data - because events are things which have already happened, event messages are generally immutable and therefore any information in the event should be true forever in case the events need to be replayed. In this instance a resource address could easily become obsolete and events would not be re-playable.

优点:

• 将服务契约与消息分离.
• 事件名称中包含的有关事件的信息.
• 自然幂等(带时间戳).
• 通常很小.
• 易于生成和使用.

缺点:

• 消费者必须进行额外调用以检索事件上下文 - 需要对其他系统有明确的了解.
• 事件上下文在消费者检索它时可能已经过时，使得这种方法通常不适合某些实时应用程序.

在引发事件时，哪种模式最适合?

When raising an event, which pattern is the most suited?

我认为这个问题的答案是:这取决于很多事情，而且可能没有一个正确的答案.

I think the answer to this is: it depends on lots of things, and there is probably no one right answer.

评论更新:同样值得一读，一篇关于消息传递的非常古老的经典博客文章:https://docs.microsoft.com/en-gb/archive/blogs/nickmalik/killing-the-command-message-should-we-use-events-or-documents(也在这里:http://vanguardea.com/killing-the-command-message-should-we-use-events-or-documents/)

Update from comments: Also worth reading, a very old, classic, blog post on messaging: https://docs.microsoft.com/en-gb/archive/blogs/nickmalik/killing-the-command-message-should-we-use-events-or-documents (also here: http://vanguardea.com/killing-the-command-message-should-we-use-events-or-documents/)

这篇关于事件驱动架构和事件结构的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！