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