将事件命名为“CustomerUpdate”
首先让我们从您的活动名称开始。事件的目的是描述某事物已经发生了。这与命令不同，命令是针对某事发出指令尚未发生.
您的事件名称“CustomerUpdate”在这方面听起来不明确，因为它可能描述过去或将来的事情。
客户更新会更好，但即便如此，Updated是另一个含糊不清的术语，并且在业务环境中并不特定。为什么在这种情况下要更新客户？是因为他们更改了付款详细信息吗？搬回家了？他们的身份是否从白银升级为黄金？事件可以根据需要变得具体。
乍一看这似乎是想太多了，但是当您从事件负载中删除数据和上下文时，事件命名变得尤其重要，更多地朝着skinny事件（您的问题中的“选项3”，我将在下面讨论）。
这并不是说在这种粒度级别上定义事件总是合适的，只是说它是在项目早期向您开放的一条途径，可能会在以后带来红利（或者可能会用数千个事件淹没您）类型）。
回到您的实际问题，让我们依次考虑您的每个选项：
将事件命名为“CustomerUpdate”并包含所有信息（更新
或不）关于客户
我们称这个“模式”为Fat信息。
胖消息（也称为快照）表示所描述实体在给定时间点的状态以及有效负载中存在的所有事件上下文。它们很有趣，因为消息本身代表了服务和消费者之间的契约。它们可用于在业务域之间传达状态变化，其中可能优选所有事件上下文在消费者处理消息期间都存在。
优点：
- 自我一致——完全可以在不了解其他系统的情况下使用。
- 易于使用（更新插入）。
缺点：
- 脆弱——服务和消费者之间的契约与消息本身耦合。
- 如果消息以错误的顺序到达，则很容易用旧数据覆盖当前数据（提示：您可以通过使用事件溯源 https://martinfowler.com/eaaDev/EventSourcing.html图案）
- Large.
将事件命名为“CustomerUpdate”并仅包含已更新的信息
真的更新了
我们称这种模式为Delta信息。
增量消息在很多方面与胖消息相似，尽管它们的生成和使用通常更复杂。一个很好的例子是JSON补丁 https://www.rfc-editor.org/rfc/rfc6902标准。
因为它们只是事件实体的部分描述，所以增量还带有一个内置假设，即消费者了解所描述的事件的一些信息。因此，它们可能不太适合在业务域之外发送，因为在业务域中事件实体可能并不为人所知。
当在共享相同实体模型的系统之间同步数据时，增量真正发挥作用，理想情况下保留在非关系存储（例如，no-sql）中。在这种情况下，可以检索实体，应用增量，然后以最小的努力再次持久化。
优点：
- 小于 Fat 消息
- 在涉及共享实体模型的用例中表现出色
- 可移植（如果基于 jsonpatch 等标准，或者在较小程度上基于 diffgram）
缺点：
- 与 Fat 消息类似，假设完全了解数据实体。
- 轻松用旧数据覆盖当前数据。
- 生成和使用很复杂（特定用例除外）
将事件命名为“CustomerUpdate”并包含最少的信息
（标识符）和/或让消费者检索信息的 URI
关于该客户。
我们称其为Skinny信息。
瘦消息与您定义的其他消息模式不同，因为服务/消费者契约不再在消息中明确显示，而是暗示消费者稍后将检索事件上下文。这将合约和消息交换解耦，这是一件好事。
这可能适合也可能不适合跨业务领域的事件通信，具体取决于您的企业的设置方式。由于事件有效负载非常小（通常是带有一些标头的 ID），因此除了事件名称之外，没有任何上下文可以供使用者做出处理决策的基础；因此，确保事件被正确命名变得更加重要，特别是当消费者可以通过多种方式处理事件时客户更新信息。
此外，在事件数据中包含实际资源地址可能不是一个好习惯 - 因为事件是已经发生的事情，事件消息通常是不可变的，因此事件中的任何信息都应该永远真实，以防事件需要被更改。重播了。在这种情况下，资源地址很容易变得过时，并且事件将无法重播。
优点：
- 将服务契约与消息解耦。
- 事件名称中包含有关该事件的信息。
- 自然幂等（带有时间戳）。
- 一般都比较小。
- 易于生成和使用。
缺点：
- 消费者必须进行额外的调用来检索事件上下文 - 需要对其他系统的明确了解。
- 事件上下文在消费者检索它时可能已经过时，使得这种方法通常不适合某些实时应用程序。
发起事件时，哪种模式最适合？
我认为这个问题的答案是：这取决于很多因素，而且可能没有一个正确的答案。
评论更新：也值得一读，一篇关于消息传递的非常古老、经典的博客文章：https://learn.microsoft.com/en-gb/archive/blogs/nickmalik/killing-the-command-message-should-we-use-events-or-documents https://learn.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/ http://vanguardea.com/killing-the-command-message-should-we-use-events-or-documents/)
