这篇来自今年ddd交换的演讲是我在事件驱动/cqrs系统中遇到的最好的资源，它与process manager/saga模式有关：https://skillsmatter.com/skillscasts/9853-long-running-processes-in-ddd （需要注册免费帐户才能查看）
在github上显示的演示：https://github.com/flowing/flowing-retail
我把它转了一圈，我很喜欢它。我确实建议先看录像来准备舞台。
尽管所示的方法与消息总线无关，但演示使用kafka让流程管理器向其他有界上下文发送命令并侦听事件。它不使用Kafka流，但我不明白为什么它不能插入Kafka流拓扑，成为更广泛的体系结构的一部分，就像您引用的指挥官演示中描述的那样。
我希望为了我们自己的需要对此进行进一步的研究，所以请随意在kafka用户邮件列表上开始一个线程，这是一个很好的协作模式的地方。
希望有帮助：-）

我想在这里补充一些关于传奇和Kafka的东西。

总的来说

总的来说，Kafka和普通的队列有点不同。它的伸缩性特别好。这实际上会引起一些并发症。
kafka使用了数据流的分区，这是实现可伸缩性的方法之一。数据被放置在分区中，分区可以以自己的速率使用，与同一主题的其他分区无关。下面是一些关于它的信息：如何选择Kafka集群。我会再谈为什么这很重要。
目前，确保Kafka内部秩序的最常见方法是：
使用1个分区作为主题
使用分区消息键将消息“分配”到主题
在这两种情况下，按时间顺序排列的相关消息需要流经同一主题。
另外，正如@pranjal thakur所指出的；确保传递方法设置为“恰好一次”，这会影响性能，但确保不会多次接收消息。

警告

现在，这里有一个警告；改变分区数量时；分区上的消息分布（使用密钥时）也将更改。
在正常情况下，这很容易处理。但是，如果您有一个高流量的情况，迁移到不同数量的分区可能会导致一个传奇-“流”在多个分区上处理，并且在这一点上不能保证顺序。
这在你的场景中是否会成为一个问题取决于你。
以下是一些问题，您可以询问这些问题以确定这是否适用于您的系统：
如果您需要使用kafka将数据迁移/复制到新系统，会发生什么情况？
（高流量场景）
你能把你的数据发送到一个主题吗？
在您的saga服务暂时中断之后会发生什么？
（低可用性场景/高流量场景）
当你需要重放一堆信息时会发生什么？
（高流量场景）
如果我们需要增加分区会发生什么？
（高流量场景/停机和恢复场景）

另一种选择

如果你想建立一个传奇，基于步骤，像一个状态机，我会挑战你重新思考一下你的设计。
我举个例子：
让我们考虑一下预订酒店房间的过程：
简单来说，它可能包括以下步骤：
预留处理室（传入事件）
处理房间付款（传入事件）
发送预订确认（在付款和一些处理之后）
现在，如果您的传奇无法处理付款，如果预订还没有进来，那么您是依赖于事件的顺序。
在这种情况下，你应该扪心自问：这个什么时候会打破？
如果你想避免时间顺序的依赖性；考虑一个没有传奇的系统，或者一个不依赖于事件顺序的传奇-例如：接受所有消息，即使在这个过程中还没有轮到它们。
一些例子：
聚合器
建模为业务流程：并行网关（并行流程流）
做笔记；在这样的设置中，更为关键的是每个动作都有一个实现的补偿动作（回滚动作）。
我知道这通常很难实现；但是，如果你从小处着手，你可能会开始喜欢它：-）