最近我读了很多关于分布式消息传递和相关模式的文章。我使用了其中一些工具支持的工具，例如 NServiceBus .
许多这些模式在互联网上都有描述。我最近读到的其中一些是:
如果使用 NService 总线这样的工具可以在不考虑基础设施问题的情况下做很多事情，那么当我尝试实现基本的消息总线和命令处理程序时，就会出现一些问题。事实上，当谈到这些模式时，我看不出它们之间有很多差异。
我不会粘贴代码，因为它太长了，但我找到了两篇博客文章，它们很好地描述了我想谈论的实现的想法。
这个想法很简单，消息总线跟踪订阅者并将消息分派(dispatch)给不同的订阅者，如果他们感兴趣的话。
它与消息总线非常相似。命令总线调用给定命令类型的命令处理程序。
所以在这两种情况下都有相似之处。
使用一种模式比使用另一种模式的真正区别和好处是什么(我不是在谈论支持工具)。 我错过了什么？
第二个问题是。 如果没有支持工具，消息总线是否有值(value)？ 我不认为自己能够独自插入对所有租户的支持。
对于一个冗长而令人困惑的问题，我深表歉意，但请不要犹豫，询问更多细节。
最佳答案
哇，很难给出比您链接到的 MSDN 更彻底或更可信的答案，所以让我们更简洁一些。
消息总线与通信有关。它甚至不需要传递的通信是否是命令。它也不关心有效载荷是什么。它是“类型不可知的”。消息总线的主要关注点只是跟踪谁应该获得每条通信(发布/订阅)。此模型的一个好处是它将支持您还没有规范的 future 扩展。您可能会在以后添加新的消息类型，该模型将很乐意提供它。消息总线更有可能分布在您的应用程序之外，甚至可能分布在您的机器之外(例如分布在 10 个服务器的集群之间)。
命令处理程序模型涉及将操作与命令的执行分开。传统上(至少在我使用的语言中)命令与 UI 控件及其事件和 UI 线程密切相关。使用这种旧模型，也很难自定义或扩展应用程序中可用命令的范围(例如使用扩展 DLL)。命令处理程序模型将 UI 和命令执行的关注点分开。您现在可以灵活地轻松添加更多命令处理程序并在没有 UI 事件的情况下执行命令(可进行单元测试)。这使得代码更清晰、更模块化和可测试。命令处理程序更有可能在内部成为应用程序的一部分。您的命令集合的任何扩展都可能旨在影响您的一个应用程序而不是多个应用程序。
消息/命令代理关注连接不兼容或设计不同的独立系统。这是您希望一个应用程序与另一个应用程序交互并且没有一个或两个应用程序的源代码的用例。因此，您创建了一个代理，它从一侧接收信息并在另一侧提供此信息，同时考虑到这两个应用程序通信所需的任何转换。 MSDN 上的示例是一个电子商务网站，它可能需要与支付处理商、运输公司和会计系统进行对话。您可能无法更改任何这些应用程序(包括电子商务系统)的源代码。也许电子商务系统需要一个 IExamplePaymentGateway 接口(interface)，而您的支付提供商需要一个 IDifferentPaymentAPI 接口(interface)。也许一个 API 用 XML 实现，另一个用 JSON 实现？无论有什么不同，您的经纪人都有责任使连接成为可能。
如您所见，它们都涉及以一种或另一种方式进行交流。它们之间的界限可能很模糊，您甚至可以使用其中几种模式的组合来实现您的特定用例。
虽然我从未使用过 NServiceBus，但这些类型的库中的大多数只是尝试将抽象/学术模型包装成更具体的语言特定实现。有时这可以节省您的时间，有时您会遇到来自未知开源贡献者的糟糕实现。您需要评估您自己的用例以及您首选开发语言中可用工具的适用性。
关于design-patterns - 对消息总线/命令调度程序模式的困惑，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/8184490/