Answers:
那么，我想念什么？
猜一猜。
您可能缺少的第一件事是，您只需要为正在重建的状态重新加载事件。如果可以清晰地对事务边界建模，则每个对象都可以写出带有其自己的ID的事件，然后仅读回这些事件。使用关系数据库进行事件存储，将有一个索引id列以加快查询速度。使用EventStore，每个对象都有自己的流。
您需要确保在模型中进行整洁的清理，因为您要确保只在每个事务中修改单个对象，因此您需要注意确保正确隔离了要尝试的每个不变量。执行。
如果速度不够快，您仍然可以创建状态快照（内存），并将其保存在“传统存储”中。每个快照都标记有用于构建快照的最后一个事件的序列号；重新加载时，存储库首先获取该快照，然后对其应用更新的事件。（这暗示了一种获取较新快照的合理方法-事件也被标上了序列号，或者您有某种有效的方法可以向后读取事件流，直到到达起点为止。）
与通常的方法相比，这里的优点仍然是，快照可以与写入并行构建，而不是与快照合并：只需将事件侦听器放在其他线程/进程中，然后愉快地将其写入以任何合理的时间表访问快照存储。毕竟，快照并不需要特别及时-只是足够频繁，以至于重新应用较新事件的工作不会破坏您的SLA。
（快照确实会使迁移复杂化；对模型的序列化所做的任何更改都将使快照缓存无效。当然，您可以使用新的序列化来重建快照，作为迁移的一部分，然后在更改生效后“追赶”。）
从事件流恢复状态是否通常已经完成？
是的。CQRS示例中通常显示的是应用程序层，在确保提交的命令格式正确之后，应用程序层将从存储库中加载域对象，该存储库中的加载是默认构造函数，然后是事件流的重播。 （或等效地，调用带有事件列表的工厂）。
另外两个矛盾的想法。