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