Design patterns 关于消息总线/命令调度器模式的混淆

最近我读了很多关于分布式消息和相关模式的文章。我使用了一些工具支持的工具，例如example

这些模式中的许多在互联网上被描述。我最近读到的其中一些是：

• 消息代理：
• 消息总线：
• SOA中的消息传递模式：
• Udi Dahan关于差异的帖子：

如果使用诸如NService bus这样的工具来做很多事情而不考虑基础设施问题，那么在我尝试实现基本的消息总线和命令处理程序时，一些问题已经解决了。事实上，当谈到这些模式时，我看不出它们之间有多少区别

我不会粘贴代码，因为它太长了，但我发现有两篇博客文章非常描述了我想讨论的实现思想

• 消息总线：

这个想法很简单，消息总线跟踪订阅者并将消息分派给不同的订阅者（如果他们感兴趣的话）

• 命令处理程序：

它非常类似于消息总线。命令总线调用给定命令类型的命令处理程序

因此，这两种情况都有相似之处

使用一种模式与另一种模式的真正区别和好处是什么（我不是说支持工具）。我缺少什么

第二个问题是如果没有支持工具，消息总线是否有价值？我不认为自己能够独自推动对所有公寓的支持

---

很抱歉，我提出了一个冗长而令人困惑的问题，但请不要犹豫，询问更多细节。

哇，很难给出一个比您链接的MSDN更全面或更可信的答案，所以让我们选择更简洁的答案

消息总线与通信有关。它甚至不要求传递的通信是否是命令。它也不关心有效载荷是什么。它是“类型不可知论者”。消息总线的主要关注点只是跟踪谁应该获得每一条通信（pub/sub）。此模型的一个好处是，它将支持您还没有规格的未来扩展。您可能会添加一种新的消息类型，这个模型将很乐意提供它。消息总线更可能分布在您的应用程序之外，甚至可能分布在您的机器之外（比如分布在10台服务器的集群之间）

命令处理程序模型涉及将操作与命令执行分离。传统上（至少在我使用的语言中）命令与UI控件及其事件和UI线程紧密关联。使用这种旧模型，还很难自定义或扩展应用程序中可用命令的范围（例如使用扩展DLL）。命令处理程序模型将UI和命令执行的关注点分开。现在，您可以灵活地轻松添加更多命令处理程序，并在没有UI事件的情况下执行命令（可进行单元测试）。这使得代码更加干净、模块化和可测试。命令处理程序更可能是应用程序内部的一部分。对commands集合的任何扩展都可能影响一个应用程序，而不是多个应用程序

消息/命令代理涉及连接不兼容或设计不同的独立系统。在这种情况下，您希望一个应用程序与另一个应用程序进行接口，但没有一个或两个应用程序的源代码。因此，您创建了一个代理，它从一端接收信息，并在另一端提供这些信息，同时考虑到这两个应用程序通信所需的任何转换。MSDN上的示例是一个电子商务网站，它可能需要与支付处理程序、航运公司和会计系统进行对话。您可能无法更改这些应用程序（包括电子商务系统）的源代码。也许电子商务系统需要一个IExamplePaymentGateway接口，而您的支付提供商需要一个IDiffertPaymentAPI接口。也许一个API是用XML实现的，另一个是用JSON实现的？无论差异有多大，您的经纪人都有责任使连接成为可能

正如你所看到的，它们都以这样或那样的方式进行交流。它们之间的界线可能很模糊，您甚至可以使用其中几个模式的组合来实现特定的用例

虽然我从未使用过NServiceBus，但大多数这类库只是试图将抽象/学术模型封装到更具体的特定语言实现中。有时这会节省您的时间，有时您会被未知开源贡献者的糟糕实现所困扰。您需要评估您自己的用例以及首选开发语言中可用工具的适用性。

通常，消息总线（或标准事件调度器）可以有多个订阅服务器，用于不同类型的消息/事件

---

命令总线通常只向一个处理器发送命令，类似于路由器解析控制器的路由。

我认为你的解释值得接受。谢谢