我的理解是这三个概念都与长时间运行的事务有关。
据我了解，流程管理器是一个有限状态机，它只是对事件做出反应并发出命令。它不包含任何业务逻辑，它只是做路由。它的目标是把你带到一个最终状态，你知道你的交易是成功还是失败。
到现在为止还挺好。
但现在我开始理解的问题：
任何人都可以解释这些差异，以及 - 我特别感兴趣的 - 这些概念中的哪些适用于什么，以及什么时候你确实需要什么。它们是相互排斥的吗？你能只带着其中一个一路走下去吗？是否存在需要多个场景的情况？……？
与流程管理器相比，saga 是什么？
这些模式的意图是不同的。流程管理器是一种工作流模式，正如您所说，它可以构建在状态机之上。流程管理器将保留消息之间的状态，并将包含逻辑以确定应采取哪些操作来响应消息（例如，转换状态或发送另一条消息）。一些框架错误地将这些称为 sagas。
相比之下，saga（根据原始定义）是一种旨在帮助管理故障的模式。它涉及跨系统的多个工作流程，其中每个工作流程都允许在以后的事务中采取某种形式的补偿措施，以防其他地方出现故障。
这种补偿是传奇的决定性特征。请注意，传奇本身并不知道补偿动作可能是什么。Sagas 通常使用路由滑动模式来实现。
它们是相互排斥的吗？你能只带着其中一个一路走下去吗？
它们不是相互排斥的——例如，参与 saga 的系统可能会使用进程管理器来实际处理其处理。
其他资源
其中一些帖子可能有助于提供更多详细信息并提供示例：
看看 MSDN 上的 CQRS Journey 项目：
http://msdn.microsoft.com/en-us/library/jj591569.aspx
澄清术语
saga 一词通常用于 CQRS 的讨论中，指的是在有界上下文和聚合之间协调和路由消息的一段代码。但是，出于本指南的目的，我们更喜欢使用术语流程管理器来指代这种类型的代码工件。有两个原因：
saga 一词有一个众所周知的预先存在的定义，其含义与通常理解的与 CQRS 相关的含义不同。术语流程管理器更好地描述了这种类型的代码工件所执行的角色。
尽管术语 saga 经常在 CQRS 模式的上下文中使用，但它有一个预先存在的定义。我们选择在本指南中使用术语流程管理器以避免与此预先存在的定义混淆。
与分布式系统相关的术语 saga 最初是在 Hector Garcia-Molina 和 Kenneth Salem 的论文“Sagas”中定义的。本文提出了一种称为 saga 的机制，以替代使用分布式事务来管理长期运行的业务流程。该论文认识到业务流程通常由多个步骤组成，每个步骤都涉及一个事务，并且可以通过将这些单独的事务分组为分布式事务来实现整体一致性。但是，在长时间运行的业务流程中，使用分布式事务可能会影响系统的性能和并发性，因为在分布式事务期间必须持有锁。
Saga 没有状态，而 Process Manager 有。
另一个区别 - Process Manager 是一个状态机，而 Saga 不是。
佐贺没有
.. 并且流程管理器有
在我的博客中阅读更多内容： http ://blog.devarchive.net/2015/11/saga-vs-process-manager.html
Saga 和 Process Manager 是两种集成模式。它们非常相似，但不完全一样。
当在设计时可能不知道所需的步骤并且可能不是连续的时，流程管理器和 saga 都会通过多个处理步骤路由消息。
流程管理器模式是一个持久的事件调度器，它封装了流程特定的逻辑并维护一个中心控制点，以决定流程完成后接下来要执行什么。流程管理器维护状态，例如说从客户那里收取了一笔款项，现在必须将订单发送给他们的事实在流程管理器中保持不变。
传奇经理模式。 封装流程逻辑，决定流程完成后下一步要执行什么。saga 没有状态，因此完全根据传入消息或事件的内容来决定下一步做什么。因此，在某个流程接受付款的情况下，该流程还会创建一条新消息，指示现在必须发送订单，包括需要发送的内容以及发送给谁。该消息还包含其他付款信息，因此如果在发送订单时出现问题，付款将被退还。