typescript - Nestjs 事件溯源 - 事件持久性

Question

Nestjs 中如何处理事件持久性？文档中并不清楚(阅读 CQRS Recipe)，我们应该如何持久化事件以及如何使用快照回复它们。它也不清楚如何创建与写入端分开的读取端。

Answer 1

文档指出“为了促进 [CQRS] 模型，Nest 提供了 轻量级 CQRS 模块。”，这正是它提供的。与 NestJS 的其他部分不同，小型 cqrs 对象模型并不是那么固执己见，为实现者留下了很多架构决策。
因此，对象模型允许以干净的方式创建 Command , Saga , Query和 Event对象并为其提供处理程序，定义 AggregateRoot实体并具有用于发布的消息总线，但仅此而已。为您提供进行领域驱动设计的基础知识。
如何整合它们完全取决于您。如果你做 Github search在“nest + cqrs”上，您会发现许多不同的方法。一些选择例如:

直接在 Controller 中创建命令而不是在应用层服务中创建命令。

命令不返回数据与仅返回错误与仅返回写入端数据。

聚合根和 DB/ORM 实体是同一类(不是 DDD 最佳实践)。

通过 eventbus 手动发出的事件与通过 mergeObjectContext 在聚合根上发出的事件。

用于读取和写入端模型的单个数据库与多个数据库。

您关于持久事件的问题是指最后一点，以及在 CQRS 之上实现事件溯源 (ES) 的提示。请注意，这样做完全是可选的。虽然 ES 带有许多有趣的特性，但您应该仅在您的应用程序要求允许的情况下应用此模式。 ES 带来了额外的复杂性，这一点不应被低估。因此，绝对建议阅读利弊( cqrs.nu 常见问题解答是一个很好的开始)。请注意，您可以只实现 CQRS，然后在需要时添加 ES。
所以事件溯源(和事件持久性)不是 NestJS CQRS 模块的一部分。当您决定持久化您的事件时，您可以使用专门的数据库，例如 Eventstore或者您可以在您的关系数据库中实现它(参见 Postgres，例如 Event Storage in Postgres 、 PostgreSQL Event Sourcing 或成熟的项目 message-db )。
使用事件溯源，您的设置可能看起来像好文章 Event-Sourcing with NestJS 中描述的内容由 Eliran Natan 撰写:

在此设置中，您必须进行预测以加载(通常)具有非规范化 View 的关系数据库，用于架构的读取端。如果没有 ES，这可能不需要，您可以使用 ORM 或直接 SQL 查询来补充您的 Query具有适当数据的对象。
就是这样。最后一个技巧是永远不要从写端代码直接调用你的读端逻辑(这是一个麻烦的秘诀，因为它破坏了命令/查询的分离)。