最近，我已经介绍了Command Dispatcher Pattern，它可以帮助在基于域驱动设计方法和CQRS模式的项目中将命令与命令处理程序分离。
无论如何，我将其与Mediator设计模式相混淆。
Robert Harvey has already answered关于Command Dispatcher模式的问题，如下所示：
Command Dispatcher是将Action-Request与 适当的动作处理程序。目的是将 从发送和接收对象命令操作，以便 彼此都不了解。
根据维基百科，The mediator pattern被描述为：
使用中介模式，对象之间的通信是 封装在中介对象中。对象不再通信 彼此直接交流，而是通过 调解员。这样可以减少通信对象之间的依赖性， 从而减少耦合。
所以，据我所知，他们都将命令与命令程序分开，这使我们能够与调用程序分离。
我已经看到了Github上的一些项目，这些项目正在使用Command Dispatcher Pattern来为请求的命令调用所需的处理程序，而其他项目正在使用Mediator模式来分发消息。 （例如，在大多数DotNet项目中，MediatR库用于满足该要求。）
但是，我想知道在我们基于DDD方法和CQRS模式的项目中，使用一种模式与使用另一种模式有什么区别和好处？
答案 0 :(得分：1)
介体模式在其纯概念上更为底层和通用。介体模式不定义通信的类型或您使用的消息的类型。在Command Dispatcher中，您处于上层（上下文和概念性），其中已经定义了通信和消息的类型。
您应该能够使用Mediator模式（使用MediatR的ergo）实现Command Dispatcher模式。
答案 1 :(得分：0)
Command Dispatcher和Mediator模式（以及Event Aggregator Pattern）具有相似之处，因为它们引入了 mediating 组件来分离组件之间的直接通信。虽然每种方法都可以用来实现设想了其他模式的用例，但它们都是具体的模式，它们在其最初的目标问题以及适合每种需求的级别上有所不同。
命令分派器模式主要是一种基于配置的约定方法，通常用于促进使用离散类型来处理应用程序和查询的UI层调用，而不是更传统的应用程序服务设计。当将查询和命令通常以分立的组件（例如CreateOrderCommand，GetOrderQuery等）表示在过程粒度服务（例如OrderService）中时，可能会在UI级组件（例如， ASP.Net MVC控制器，在此情况下，构造函数可能需要注入一系列离散的接口，每个用户请求（例如Controller Action）通常通常只需要其中的一个。引入调度程序可以大大减少实现ASP.Net MVC控制器等组件所需的代码量，因为唯一需要注入的依赖项就是调度程序。尽管不一定是该模式的主要动机，但它还引入了统一应用其他模式（例如管道和过滤器）的功能，并提供了一个接缝，可以在运行时确定命令处理程序的实现。 MediatR库实际上就是这种模式的实现。
介体模式涉及创建中介组件，这些组件封装了特定于域的编排逻辑，否则将需要组件之间的耦合。也就是说，在这种情况下，中介组件不仅是愚蠢的调度程序（“ 嘿，任何人都知道如何处理XYZRequest吗？”），而是专门为遵循特定的集合而构建的。给定操作发生时可能需要跨多个组件进行的操作数量。 GoF设计模式一书中给出的示例是一个UI组件，其中包含许多相互连接的元素，因此对一个组件的更改需要对许多其他组件进行更改，反之亦然（例如，在文本字段中键入会导致下拉列表的更改以及多个复选框和单选按钮，同时在下拉效果中选择条目会更改为文本字段，复选框和单选按钮等。）通过提供的解决方案，中介组件包含逻辑，以准确地知道哪些组件需要更新以及其他组件何时更改。
因此，当您需要定制组件以促进许多其他组件之间的交互方式时，将使用中介器模式，而正常的耦合将对可维护性产生负面影响，而命令分派器模式仅用作傻瓜功能路由器，将调用者与被调用函数解耦。