了解DDD上下文中的命令模式
我最近在这里阅读这篇文章： 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)
它似乎谈论使用命令而不是应用程序服务。
不，它没有谈论命令设计模式。 在我的博客和其他地方描述的命令设计模式和类似CQRS的模式之间存在非常明确且至关重要的区别。
命令设计模式中的“命令”组合了同一类中的数据和行为 。 使用CQRS，该命令只是一条没有行为的消息。 行为被移动到“处理程序”类。 这种分离是驱动器，可实现此设计的可维护性和灵活性。
1）这是说在应用服务层中每个命令请求应该有一个命令吗？ 如果您有100个命令，这不会导致类爆炸吗？
这是与开发人员非常常见的误解。 他们认为系统中的类型数量与该系统的可维护性之间存在直接关系，其中类别的增加意味着可维护性的降低。
然而，SOLID设计模式有利于小型和集中式类而不是大类，因为使类更小，实际上可以极大地提高系统的可维护性。
这正是这里发生的事情。 应从SOLID的角度来看待这种设计。 我的经验是，在我重构到该模型的系统中，我们看到可维护性大幅增加了一个数量级，即使类的数量也会增加一个数量级。
不要担心系统中的类数。 只是担心可维护性。
这并不意味着项目结构无关紧要。 事实并非如此。 因此，为您的命令，处理程序和装饰器找到一个好的项目结构。
2）你如何处理CQRS查询？ 您是否为这些创建常规应用程序服务？
查询与命令完全相同。 每个查询都应该有自己的查询消息和处理程序，以及可选的结果消息类。 此博客文章介绍了如何设计查询。
3）你如何处理从数据库中提取的场景（比如一个订单）; 在订单上执行一个命令，例如CalculateTax，然后坚持到数据库？ 我假设流程是（这是正确的）：
这是一个primefaces操作，应该都是命令的一部分。 执行该命令时，将根据在命令中捕获的ID从数据库加载订单。 计算税额并将订单作为该（业务）交易的一部分保留。