我正在努力理解 sagas ，同时我有一种特定的思考方式 - 但我不确定我的想法是否正确。因此，我想详细说明并让其他人告诉我这是对还是错。
根据我的理解，传奇是解决如何模拟长期运行流程的问题的解决方案。长时间运行意味着：涉及多个命令，多个事件以及可能的多个聚合。该进程未在其中一个参与聚合内建模，以避免它们之间存在依赖关系。
基本上，saga只不过是一个对内部和外部命令/事件做出反应的命令/事件处理程序。它不包含自己的逻辑，它只是一个（有限的）状态机，因此提供诸如当事件X发生时的任务，发送命令Y 。
Sagas持久存储到事件存储以及聚合，与特定的聚合实例相关联，因此在使用此特定聚合（或聚合集合）时会重新加载。
这是对的吗？
答案 0 :(得分：8)
实施Sagas有不同的方法。从无状态事件处理程序到达，它们一直发布命令以承载所有状态，并且基本上是域的聚合本身。 Udi Dahan曾写过一篇关于Sagas是（在他的具体情况下）正确建模系统中唯一的聚合物的文章。我会查阅并更新这个答案。
还有基于文档的传奇的概念。
答案 1 :(得分：7)
你对Sagas的定义听起来适合我，我也会定义它们。
我的描述中唯一的变化是，saga只是事件的事件处理程序（而不是命令），并且基于接收事件，其内部状态构造命令并将其命名为CommandBus for执行。
通常，Saga只有一个事件要从（StartByEvent）启动，多个事件要转换（TransitionByEvent）到下一个状态，多个事件要由（EndByEvent）结束。
在MSDN上，他们将Sagas定义为ProcessManager。
答案 2 :(得分：3)
术语saga通常用于讨论CQRS以引用a 在有界区域之间协调和路由消息的代码片段 上下文和聚合。但是，出于本指南的目的，我们 我更喜欢使用术语流程管理器来引用这种类型的代码 神器。这有两个原因：有一个众所周知的， 已有的具有不同含义的saga一词的定义 来自与CQRS有关的一般理解。术语 流程管理器是对此执行的角色的更好描述 代码工件的类型。虽然术语传奇常用于 在CQRS模式的上下文中，它具有预先存在的定义。我们有 选择在本指南中使用术语流程管理器来避免 与这个先前存在的定义混淆。传说中的传奇 与分布式系统的关系最初是在论文中定义的 Hector Garcia-Molina和Kenneth Salem的“Sagas”。本文提出 一种机制，它称为传奇作为使用a的替代方法 用于管理长期运行的业务流程的分布式事务。 本文认识到业务流程通常由 多个步骤，每个步骤涉及一个事务，总体而言 通过对这些单独的交易进行分组可以实现一致性 进入分布式事务。但是，在长期经营中 进程，使用分布式事务可以影响 由于锁定，系统的性能和并发性 必须在分发交易期间持有。