design-patterns - Command + CommandHandler 和 Service 有什么区别？

Question

我一直在阅读有关使用 Command 对象来表示我们的域公开的用例，以及使用 Command Handler 对象来处理这些命令的内容。

例如:

• 注册用户命令
• RegisterUserCommandHandler

但它看起来与 RegisterUserService 完全相同，其中命令对象代表 registerUser() 方法的参数。

当然，如果该方法有太多参数，我最终会创建一个对象来包装它们，并且该对象将与 RegisterUserCommand 相同。

那么为什么要用不同的模式来表示同一事物呢？服务是广泛存在的，而不是命令(根据我的经验)；我所缺少的有什么区别？简而言之，为什么我要使用其中一种而不是另一种？

Answer 1

拥有命令可以给你带来良好的旧命令模式的好处:

• 你可以参数化一个对象，例如一个 UI 元素，带有要执行的命令
• 您可以存储命令并稍后执行，例如在队列或事务日志中
• 您可以跟踪您执行的命令，为您实现撤消奠定基础

如果您的服务很大，每个服务都有许多复杂的方法(如果这些方法不复杂，您可能不应该使用 DDD 或 CQRS)，那么将每个方法移动到命令处理程序中可能会改进您的应用程序可组合性更强、更易于测试等。毫无疑问，对于直接从大型服务重构为命令/命令处理程序的人来说，通常会认为这是后一种模式的好处。但是，通过将大型服务分解为较小的服务(如示例中非常具体的服务所建议的那样)，您可以获得相同的好处，因此严格来说，这在服务和命令/命令处理程序之间没有区别。