Architecture 每个命令都有事件源？

我有一个事件源系统，它由CQRS模式补充。 如果命令有效，则向服务器发出的每个命令都将使用事件流将我的聚合（新初始化的聚合）重新水合到当前状态

我的问题是-为什么我要对每个命令重新添加聚合状态？为什么我不能只为每个聚合Id保留一个聚合实例，而不用担心对每个命令进行重新水合？在这个场景中，我只会在启动服务器时重新生成事件

这样做有什么不对吗？它仍将保留国家的历史，因为事件将继续存在

谢谢

编辑：我正在每n个事件对我的聚合状态进行快照，因此我不必每次重新水合超过n个事件。此外，每次保存新快照以保存状态请求时，我都会缓存聚合状态。我更想知道，如果我可以在内存中保留一个正在运行的聚合实例（每个aggregateId），为什么还要重新水合呢

为什么我不能只为每个聚合Id保留一个聚合实例，而不用担心对每个命令进行重新水合

当然，这很好——通过在内存中缓存聚合的表示形式，您可以节省一些工作

---

如果有多个进程可以更改事件流，则会变得更困难；您需要做一些额外的簿记工作，以便在本地缓存的副本与最新编辑不同步时，不会错误地计算事件。

我同意@voiceofunreason在几乎所有情况下（从个人经验来看），存储\缓存“当前”聚合状态是完全正确的。但是，您应该意识到，这样做可能会遗漏一些东西：

您没有对骨料进行再水化。这可能会将版本控制问题隐藏足够长的时间，从而成为一个大问题。可以认为这与备份数据库类似，但从不测试恢复

通过存储缓存，您将错失使用延迟火灾事件的机会。例如，您可以举办类似“11月后适用新定价”的活动。一旦有了此事件，您将存储它，但它只会在特定日期后影响状态（定价）。诚然，这是一种特殊的情况（当然也不是特别常见），但这是你将失去的东西

您将无法进行（双）时态查询，如“我当时对X aggregate了解多少”

第1点比其他点更重要，但有一些方法可以解决这一问题，但每次都不需要重新水化。只是在许多情况下，补液是一个很好的选择

在事件旁边使用快照，并使用快照+更新的事件重新水化可以解决这些问题，因为：

在你抓拍快照之前，重新布置

当您有一个“late fire事件”时，由于快照与事件并排存储，因此很容易停止快照，直到late fire事件应用，之后您就可以进行快照了

您可以绕过快照进行临时查询

---

好的，我正在使用缓存的聚合状态作为快照的一部分，然后重新水合在此快照上次记录的事件版本之后发生的事件。这使得我不必对每个命令都进行完全重新水合，但在保存和缓存新快照之前，仍然需要进行一些重新水合。这似乎是一个不错的方法吗？或者我可以不再需要进一步补充水分吗？另外，你介意定义一下你这里所说的过程是什么意思吗？只有在命令经过验证且聚合状态成功处理了新事件后，事件才会被追加。@Lamar进程在术语的操作系统意义上，即使用单独的内存沙盒。更不用说集群/web场（除非使用分布式缓存）。