我已经读过，在NServiceBus中，命令总是在一个地方处理。这是一般的CQRS /事件采购经验法则吗？如果是，有什么好处？为什么扩展命令处理节点是个坏主意？
答案 0 :(得分：1)
命令表示更改业务状态的特定部分的意图。只有一个命令处理程序，即实现该功能的一个地方是有意义的。此外，在命令处理程序中，我们实现了一个具有自己的模型和边界的业务用例。
您可以通过添加更多端点来扩展命令处理程序，但它是并行运行的相同代码，这是一个风险很大的事情，尤其是在分布式应用程序中。垂直扩展更容易，也更便宜，但我要说很少有应用类型需要扩展命令端。
答案 1 :(得分：0)
消息传递的基本目标可以帮助我们通过维护每个组件的自治性和逻辑“服务”来实现组件之间的松散耦合。
通常，通过使用显式命名，应该清楚您期望消息处理程序执行什么操作。结合“单一责任原则”（SRP），我们可以更好地分解我们的系统。例如，“UpdateUser”表示什么都没有，而“UpdateUserPhoneNumber”或“ChangeUserPassword”更像是： - ）。
我们希望确保我们不混合逻辑（例如，所有这些都属于我的财务“服务”）和物理可部署服务（进程）。 可能有许多物理进程（Windows服务，IIS / WEB进程，WCF，桌面应用程序）托管逻辑“服务”的部分或混合多个逻辑“服务”。
使用命令/事件语义阐明了消息的意图和逻辑边界。
命令： - 使用命令完成逻辑“服务”边界内的组件之间的内部通信。 - 命令（顾名思义）可以命令逻辑“服务”边界内的另一个组件。 - 它们改变处理组件的状态。 - 它们包含组件（处理程序）执行其任务所需的数据和上下文。 - 命令被“发送”（使用NServiceBus使用bus.Send（））到一个组件（处理程序）（一对一通信）。
活动： - 事件用于交叉逻辑“服务”通信。 - 他们通知过去发生的事情。 - 它们很轻，只包含Ids和少量上下文数据等参考数据。 - 发布事件（使用NServiceBus的bus.Publish（）） - 只有一个逻辑发布者和一个或多个订阅者。 - 事件也可以在内部松耦合组件之间的逻辑“服务”内使用。
总结： 使用逻辑“服务”边界内的数据命令来更改状态。 将事件与参考数据一起用于跨逻辑“服务”通信。 遵循单一责任原则，它将有助于减少您的工作单元的规模。 减少耦合是我们的目标。
这有意义吗？