了解DDD上下文中的命令模式 [英] Understanding the Command pattern in a DDD context

问题描述

我最近在这里阅读这篇文章： https：// cuttingedge .it / blogs / steven / pivot / entry.php？id = 100 。似乎是在谈论使用命令（ http://www.dofactory.com/net/

I was recently reading this article here: https://cuttingedge.it/blogs/steven/pivot/entry.php?id=100. It appears to talk about using commands (http://www.dofactory.com/net/command-design-pattern) instead of application services.

请参见下面的代码：

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条命令？

1) Is this saying that you should have one command per command request in the Application Service Layer? Wouldn't this result in class explosion e.g. if you have 100 commands?

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

2) What do you do with CQRS queries? Do you create regular application services for these?

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

3) What do you do with scenarios where you extract from the database (say an order); perform a command on the Order e.g. CalculateTax and then persist to the database? I assume the flow would be (is this right):

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

推荐答案

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

It appears to talk about using commands instead of application services.

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

No, it does not talk about the command design pattern. There is a very clear, and crucial distinction between the command design pattern, and the CQRS-like patterns that are described on my blog and elsewhere.

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

The 'command' in the command design pattern combines data and behavior within the same class. With CQRS, the command is simply a message with no behavior. Behavior is moved to a 'handler' class. This separation is the driver that enables the maintainability and flexibility of this design.

1）就是说，每个命令应该有一个命令在应用服务层请求？这不会导致类爆炸吗如果您有100条命令？

1) Is this saying that you should have one command per command request in the Application Service Layer? Wouldn't this result in class explosion e.g. if you have 100 commands?

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

This is a very common misconception with developers. They think there is a direct relationship between the number of types in the system and the maintainability of that system, where an increase in classes means a decrease of maintainability.

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

The SOLID design patterns however favor small and focussed classes over big classes, because making classes smaller, can actually increase the maintainability of a system tremendously.

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

This is exactly what's going on here. This design should be viewed from the point of SOLID. My experience that, within the systems I refactored to that model, we saw a massive increase in maintainability in an order of magnitude, even though the amount of classes would as well increase with an order of magnitude.

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

Do not worry about the number of classes in your system. Just worry about maintainability.

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

This doesn't mean that project structure is irrelevant. It isn't. So find a good project structure for your commands, their handlers and their decorators.

2）您对CQRS查询做什么？您是否为这些应用程序创建常规的应用程序服务？

2) What do you do with CQRS queries? Do you create regular application services for these?

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

You do exactly the same to queries as you do to commands. Each query should have its own query message and a handler, and optionally a result message class. This blog post describes how to design you queries.

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

3) What do you do with scenarios where you extract from the database (say an order); perform a command on the Order e.g. CalculateTax and then persist to the database? I assume the flow would be (is this right):

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

This is an atomic operation and should all be part of the command. When the command is executed, the order is loaded from the database, based on its ID captured in the command. The tax is calculated and the order is persisted as part of that (business) transaction.

这篇关于了解DDD上下文中的命令模式的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！