了解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

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

不，它没有讨论命令设计模式。命令设计模式和我的博客以及其他地方介绍的类似CQRS的模式之间存在非常明显且至关重要的区别。

命令设计模式中的“命令” 将同一类中的数据和行为组合在一起。使用CQRS，该命令只是一条无行为的消息。行为将移至“处理程序”类。这种分离是使该设计具有可维护性和灵活性的驱动力。

1）这是否意味着在应用程序服务层中每个命令请求应该有一个命令？例如，如果您有100条命令，这不会导致类爆炸吗？

这是开发人员非常普遍的误解。他们认为系统中类型的数量与系统的可维护性之间存在直接关系，类别的增加意味着可维护性的下降。

但是，SOLID设计模式比小类和重点突出的类优先于大类，因为使类更小实际上可以极大地提高系统的可维护性。

这就是这里正在发生的事情。此设计应从SOLID的角度来看。我的经验是，在我重构为该模型的系统中，尽管类的数量也会随着数量级的增加而增加，但可维护性却在一个数量级上得到了极大的提高。

不必担心系统中的类数。只是担心可维护性。

这并不意味着项目结构无关紧要。不是。因此，为您的命令，其处理程序和装饰器找到一个好的项目结构。

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

您对查询的操作与对命令的操作完全相同。每个查询都应具有自己的查询消息和处理程序，还可以选择结果消息类。这篇博客文章描述了如何设计查询。

3）您如何处理从数据库中提取的情况（例如订单）？在订单上执行命令，例如CalculateTax，然后将其保存到数据库？我认为流程是（是对的）：

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