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