在构建事件驱动架构时，您将使用消息/事件在系统之间传递信息。这些消息的内容取决于您。这很好，因为它变得灵活，但同时也是一个问题，因为它很灵活！
许多构建事件驱动解决方案的人都是从在系统之间引发消息/事件开始的，而没有过多考虑事件设计。
- 您的事件活动包含哪些内容？
- 您的活事件动中应该包含哪些内容？
多年后，由于缺乏设计，许多人的版本、文档和消费者结构会发现很难理解这些事件的有效负载。
防止生产者和消费者之间的混淆
- 事件驱动的架构对我们来说变得越来越容易，越来越多的生产者和消费者被集成到系统中。
- 糟糕的事件设计可能会导致生产者和消费者之间的集成混乱。
- 事件需要明确的命名意图，这有助于在每个事件中制定标准。
- 标准使您可以更轻松地对事件进行版本控制、验证事件以及编写支持事件的工具。
- 您可以在内部指定自己的标准，也可以依靠CloudEvents来帮助您定义标准。
- 在构建事件驱动架构时考虑你的事件设计，考虑其他人将如何消费这些事件。
- 不要在您的事件中暴露实现细节。
事件第一思维
- 在设计 APIS 时，我们倾向于编写文档、规范、版本控制策略等等。在设计活动时，情况就不同了。
- 在设计您的活动时，请借鉴我们从 API 管理中学到的知识，并将这些原则应用到您的活动设计中。
- 考虑一下您将如何对您的活动进行版本控制，谁是您活动的目标受众？您要记录您的事件吗？
- 如果事件是集成事件，请使用组织内的领域专家来帮助您设计事件。
- 考虑您正在设计什么类型的事件活动，是私人活动还是集成活动。两者意味着不同的东西，你的设计会影响这一点。
- 不要让事件成为事后的想法。考虑一些预先设计和演化策略。首先考虑事件。
糟糕的设计会减慢集成速度
- 糟糕的活动事件设计会减慢生产者和消费者之间的整合。
- 事件驱动的架构依靠消费者的进出和设计解耦架构而蓬勃发展。糟糕的活动事件设计会减慢这一过程并导致挫败感。
- 清楚事件的命名和事件负载，考虑要公开的字段以及它们的命名/意图。
- 不要让消费者猜测您的字段的含义，要明确他们的意图。
- 确保您了解并能够释放活动事件的价值。
- 考虑一下标准，您希望在您的活动事件中包含哪些标准？您的命名约定是什么？您想要包含哪些标头？