我们有两个长时间运行的saga，它们都运行无限长的时间并响应超时。第一个订阅每15分钟一次超时，第二个订阅每24小时一次。每个传奇都会跟踪自己的执行时间，并在开始运行和完成时通知另一个传奇。由于数据库争用，这些saga负责的大容量数据加载无法同时运行。
当第一个传奇（Saga A-15分钟）开始时，它首先检查（使用内部变量）第二个传奇（Saga B-24小时）当前是否正在运行。如果没有，它将开始处理步骤（进入另一个进程，并随着时间的推移对其进行轮询，以查看何时完成）。这两个saga通过发送消息进行通信，以便在启动或完成时相互通知。
出于某种原因，这在两个层面上对我来说似乎很臭：
- 我们基本上有一个永远不会完成的单身传奇。这本身就是一种反模式吗
- 我们双向发送消息的唯一目的是修改状态。似乎应该有更好的方法来处理这种情况。随着NSB 4.0的发布，我们开始在
sending命令时出现错误。当我们改用pub-sub方法时，错误就消除了
这被认为是NServiceBus实现的反模式吗？对于这类需求，有更好的模式吗？
一般来说，我不认为sagas之间的通信是一种反模式。然而，在你的具体情况下，它听起来确实很臭。
从你所说的行为来看，这似乎是一个单一的传奇故事。一个传奇可以请求不同类型的多次超时。因此，您可以有效地合并这些saga，但这样您就可以删除所有存在的消息，这些消息只是为了修改同级中的状态，因为状态是共享的。
然而，从一般意义上讲，传奇人物进行交流是完全可以的。应该小心处理通过命令执行的操作，因为这会在两者之间产生直接耦合，尽管这仍然是可能的。一个例子是父子传奇对，其中父工作流命令子工作流开始，但子工作流是独立的，直到它回复其父工作流完成为止。我们只是意识到，这些是在同一服务边界内紧密耦合的过程。我们这样做可能只是为了让每个传奇故事更加集中，或者因为父母用不同的数据开始了多个孩子的传奇故事。
一个更好的例子是通过事件进行传奇式的交流。一个传奇将发布一个事件，另一个传奇则将以自己的长期流程进行回应。这一切都是解耦的，而且很好。然而，如果第二个传奇发布了第一个响应的事件，那么即使你使用的是事件，你也已经创建了一个循环，所以它与当时的命令没有什么不同，尽管它仍然与任何其他外部订阅者解耦。