我试图理解sagas，同时我对它们有一种特定的思考方式——但我不确定我的想法是否正确。因此，我想详细说明并让其他人告诉我这是对还是错。
在我的理解中，sagas 是解决如何为长时间运行的流程建模的问题。长时间运行意味着：涉及多个命令、多个事件以及可能的多个聚合。该过程不在参与聚合之一内建模，以避免它们之间的依赖关系。
基本上，saga 只不过是对内部和外部命令/事件做出反应的命令/事件处理程序。它不包含自己的逻辑，它只是一个（有限）状态机，因此提供了诸如当事件 X 发生时，发送命令 Y等任务。
Sagas 被持久化到事件存储以及聚合中，与特定聚合实例相关联，因此在使用该特定聚合（或一组聚合）时会重新加载。
这是正确的吗？
有不同的方法来实现 Sagas。从发布命令的无状态事件处理程序一直到携带所有状态并且基本上是域的聚合本身。Udi Dahan 曾经写过一篇关于 Sagas 是（在他的特定情况下）正确建模系统中的唯一聚合的文章。我会查找并更新此答案。
还有基于文档的 sagas 的概念。
你对 Sagas 的定义听起来很适合我，我也会这样定义它们。
我对您的描述所做的唯一更改是，saga 只是事件的事件处理程序（不是命令），并且基于接收事件及其内部状态构造一个命令并将其发送到 CommandBus 以执行。
通常一个 Saga 只有一个事件从 (StartByEvent) 开始，多个事件转换 (TransitionByEvent) 到下一个状态，多个事件由 (EndByEvent) 结束。
在MSDN上，他们将 Sagas 定义为 ProcessManager。
saga 一词通常用于 CQRS 的讨论中，指的是在有界上下文和聚合之间协调和路由消息的一段代码。但是，出于本指南的目的，我们更喜欢使用术语流程管理器来指代这种类型的代码工件。这有两个原因： saga 一词有一个众所周知的预先存在的定义，其含义与通常理解的与 CQRS 相关的含义不同。术语流程管理器更好地描述了这种类型的代码工件所执行的角色。尽管术语 saga 经常在 CQRS 模式的上下文中使用，但它有一个预先存在的定义。我们选择在本指南中使用术语流程管理器以避免与此预先存在的定义混淆。传奇这个词，关于分布式系统，最初是在 Hector Garcia-Molina 和 Kenneth Salem 的论文“Sagas”中定义的。本文提出了一种称为 saga 的机制，以替代使用分布式事务来管理长期运行的业务流程。该论文认识到业务流程通常由多个步骤组成，每个步骤都涉及一个事务，并且可以通过将这些单独的事务分组为分布式事务来实现整体一致性。但是，在长时间运行的业务流程中，使用分布式事务可能会影响系统的性能和并发性，因为在分布式事务期间必须持有锁。赫克托·加西亚-莫利纳和肯尼斯·塞勒姆。本文提出了一种称为 saga 的机制，以替代使用分布式事务来管理长期运行的业务流程。该论文认识到业务流程通常由多个步骤组成，每个步骤都涉及一个事务，并且可以通过将这些单独的事务分组为分布式事务来实现整体一致性。但是，在长时间运行的业务流程中，使用分布式事务可能会影响系统的性能和并发性，因为在分布式事务期间必须持有锁。赫克托·加西亚-莫利纳和肯尼斯·塞勒姆。本文提出了一种称为 saga 的机制，以替代使用分布式事务来管理长期运行的业务流程。该论文认识到业务流程通常由多个步骤组成，每个步骤都涉及一个事务，并且可以通过将这些单独的事务分组为分布式事务来实现整体一致性。但是，在长时间运行的业务流程中，使用分布式事务可能会影响系统的性能和并发性，因为在分布式事务期间必须持有锁。该论文认识到业务流程通常由多个步骤组成，每个步骤都涉及一个事务，并且可以通过将这些单独的事务分组为分布式事务来实现整体一致性。但是，在长时间运行的业务流程中，使用分布式事务可能会影响系统的性能和并发性，因为在分布式事务期间必须持有锁。该论文认识到业务流程通常由多个步骤组成，每个步骤都涉及一个事务，并且可以通过将这些单独的事务分组为分布式事务来实现整体一致性。但是，在长时间运行的业务流程中，使用分布式事务可能会影响系统的性能和并发性，因为在分布式事务期间必须持有锁。