想象系统 A 广播系统 B 感兴趣的事件 E。作为 E 的结果，B 生成自己的事件 E'，该事件也被广播。 E' 是否应该在其中包含触发它的事件（即 E），以防它在以后变得有用以了解导致创建 E'?
如果它并不总是有用，是否有许多场景可以方便地跟踪事件的历史？
提前致谢！
PD：我意识到您可以进一步扩展此论点并以非常重的事件结束（如果您的消息流描述了一个循环，甚至无限大）。考虑在这种情况下只为直接发起的事件保留一个标识符。
【问题讨论】：
标签： events event-driven event-driven-design
我会根据我目前的经验给出答案。如果它与您自己的经历不同，我想听听！
虽然是一个有趣的概念，但包含其先前事件的事件是不切实际的。俄罗斯娃娃式事件通过将它们捆绑在一起来阻碍其图式的演变。
如果事件 E' 包含其前身事件 E，则对 E 架构的任何（非向后兼容）更改都必然需要E' 的包含架构的更改。想象一下将该限制应用于一系列事件！
易于演变似乎是事件驱动架构的关键，将应用程序分成不同的可部署项只是为了通过它们产生的事件的模式再次将它们捆绑起来，几乎没有什么好处。
同样，虽然理论上很有趣，但我也没有发现这样做的商业案例，我通常不得不转发与事件链相关的信息，例如客户 ID、订单 ID 或类似信息，但从来没有转发完整的事件.存在于整个事件链中的随机生成的人工 id（从某种意义上说，它没有商业意义）对于调试/监控目的很有用（例如，找出事件在生态系统中的传播程度）。
【讨论】：