想象系统 A 广播事件 E ，这是系统 B 感兴趣的。作为 E 的结果， B 生成了自己的事件 E'，该事件也得到了广播。如果 E'中应包含触发它的事件（即 E ），以防日后理解引起该事件的动因是< em> E'？
如果它并不总是有用的，那么在某些情况下可以方便地跟踪事件的历史吗？
谢谢！
PD：我意识到您可以进一步扩展此参数，并导致非常严重的事件（如果消息流描述一个周期，则可能甚至无限大）。在这种情况下，请考虑仅保留直接发生事件的标识符。
答案 0 :(得分：0)
我将根据到目前为止的经验给出答案。如果您的经历与您的经历有所不同，我想听听！
尽管有一个有趣的概念，但包含其先前事件的事件是不切实际的。像俄罗斯玩偶一样的事件通过将它们绑在一起来阻碍其图式的演变。
如果事件 E'包含其前任事件 E ，则对 E 架构的任何（非向后兼容）更改都将需要 E'的包含架构中的更改。想象一下将限制应用于一系列事件！
易于演化似乎是事件驱动的体系结构的关键，将应用程序划分为不同的可部署对象只是通过它们产生的事件的模式将它们重新绑在一起几乎没有什么好处。
再说一次，尽管从理论上讲很有趣，但我也没有找到这样做的商业案例，我通常不得不转发与事件链相关的信息，例如客户ID，订单ID或类似事件，但从来没有完整的事件。遍布事件链的随机生成的人工ID（在某种意义上没有商业意义）对于调试/监视目的（例如，找出事件在整个生态系统中的传播程度）很有用。