（4）投影预测Projections
在事件采集中，我们也有一个投影的概念，即事件流中的事件的计算，从特定时刻开始。这意味着快照或实体的当前状态符合预测的定义。但是在预测概念中最有价值的想法是，我们可以在特定时期分析实体的“行为”，这使我们能够对未来作出有根据的猜测（即如果在过去的5年中，实体有8月份的活动增加，明年8月份可能会发生同样的事情），这对业务来说可能是非常有价值的。
（5）利弊
事件溯源对于业务和开发过程都是非常有用的：
1.我们查询这些事件，用于业务和开发，以了解用户和系统行为（调试）;
2.我们还可以使用事件日志重建过去的状态，对于业务和开发来说都是有用的;
3.自动调整状态以应对追溯变化，非常适合企业需要频繁变化;
4.通过在重播时注入假想事件来探索其他历史，令人敬畏。
但不是一切都是好消息，要注意隐藏的问题：
1.外部更新
当我们的事件在外部系统中触发更新时，但是我们又在重播事件以便创建投影，因此我们不想重新触发这些事件。在这一点上，当我们处于“重播模式”时，我们可以简单地禁用外部更新，也可以将该逻辑封装在网关中。
另一个解决方案取决于实际问题，可能是将外部系统更新放入缓冲，在一段时间后执行，保证事件不会被重播时再进行。
2.外部查询
当我们的事件使用对外部系统的查询，如获得股票评级，当我们重播事件以创建投影时会发生什么？我们可能希望获得与事件在第一次运行时所使用的相同的等级，也许是在几年前。因此，远程应用程序可以给我们这些值，或者我们需要将它们存储在系统中，所以我们可以通过在网关中封装该逻辑来模拟远程查询。
3.代码更改
Martin Fowler发现3种类型的代码更改：新功能，错误修复和时间逻辑。当在不同的时间点播放应该使用不同业务逻辑规则的事件时，真正的问题就出现。去年的税收计算与今年不同。像往常一样，条件逻辑可以使用，但它会变得凌乱，所以建议使用策略模式。
所以，我建议谨慎对待，尽可能遵循这些规则：
1.保持事态愚蠢，只关心状态的变化，而不是如何被改变的。这样我们可以安全地重播任何事件，并期望结果是一样的，即使业务规则同时发生变化（尽管我们需要保留旧的业务规则，以便我们可以在重播过去的事件时应用它们）;
2.与外部系统的交互不应该依赖于这些事件，这样我们可以安全地重播事件，而不会重新触发外部逻辑，我们不需要确保来自外部系统的回复与最初的事件相同。
