了解 DDD 上下文中的命令模式

Question

我最近在这里阅读这篇文章：https://cuttingedge.it/blogs/steven/pivot/entry.php?id=100。它似乎在谈论使用命令 (http://www.dofactory.com/net/command-design-pattern) 而不是应用程序服务。

请看下面的代码：

public sealed class ShipmentController
{
    private readonly ICommandDispatcher dispatcher;

    public void ShipOrder(ShipOrder cmd) => dispatcher.Dispatch(cmd);
}

sealed class CommandDispatcher : ICommandDispatcher
{
    private readonly Container container;

    public void Dispatch(dynamic cmd) => GetHandler(cmd.GetType()).Handle(cmd);

    private dynamic GetHandler(Type type) =>
        container.GetInstance(typeof(ICommandHandler<>).MakeGenericType(type));
}

替换如下代码：http://www.zankavtaskin.com/2013/11/applied-domain-driven-design-ddd-part-6.html

我有三个问题：

1) 这是否是说应用服务层中的每个命令请求都应该有一个命令？这不会导致班级爆炸，例如如果你有 100 个命令？

2) 您如何处理 CQRS 查询？您是否为这些创建常规应用程序服务？

3) 你如何处理从数据库中提取的场景（比如订单）；对订单执行命令，例如CalculateTax 然后持久化到数据库？我假设流程是（对吗）：

MVC 
Application Service (to extract order from database)
Command (Application Service calls CalculateTaxCommand)

Answer 1

它似乎在谈论使用命令而不是应用程序服务。

不，它没有谈论命令设计模式。 Command design pattern 与我的博客和其他地方描述的类似 CQRS 的模式之间有一个非常明确且至关重要的区别。

Command 设计模式中的“命令”将 data 和 behavior 结合在同一个类中。另一方面，对于 CQRS，命令只是一个消息，一个数据容器，没有任何行为。行为被移至“处理程序”类。处理程序与旧的“应用程序服务”相同，区别在于处理程序的范围非常狭窄。这种分离是实现此设计的可维护性和灵活性的驱动因素。

1. 这是否是说应用服务层中的每个命令请求都应该有一个命令？这不会导致班级爆炸，例如如果你有 100 个命令？

开发人员很常见的误解是认为系统中的类型数量与其可维护性之间存在直接的反向关系；类的增加意味着可维护性的降低。

然而，SOLID design patterns 偏爱小而专注的类而不是大类，因为缩小类实际上可以极大地提高系统的可维护性。q

这正是这里发生的事情。这个设计应该从SOLID的角度来看。我的经验是，在我重构为该模型的系统中，我们看到可维护性大幅提高了一个数量级，尽管类的数量也可以增加一个数量级。

提示：不要担心系统中的课程数量。只需担心可维护性。

但这并不意味着项目结构无关紧要——它肯定是相关的。您应该为您的命令、它们的处理程序和它们的装饰器找到一个好的项目结构。在 this blog post 的 the comments 中，有一些关于如何构建项目的想法。

1. 您如何处理 CQRS 查询？您是否为这些创建常规应用程序服务？

您对查询执行的操作与对命令执行的操作完全相同。每个查询都应该有自己的查询消息和处理程序，以及可选的结果消息类。 This blog post 描述了如何设计查询。

1. 您如何处理从数据库中提取的场景（例如订单）；对订单执行命令，例如CalculateTax 然后持久化到数据库？我假设流程是（对吗）：

这是一个原子操作，都应该是命令的一部分。执行命令时，会根据在命令中捕获的 ID 从数据库中加载订单。税款被计算出来，订单作为该（业务）交易的一部分被保留。