将CQRS命令直接传递给Domain对象 [英] Passing CQRS commands directly to Domain objects

问题描述

〜TLDR：我正在为我的一个较大的项目实现CQRS + DDD解决方案，并且我想知道命令处理程序是否有任何真正的原因不能直接将命令对象分派给我的聚合，在少数情况下，命令对象的数据丰富吗？我找不到任何将其作为反样式的特定原因，也找不到针对此类设计的详细说明的任何意见。

~TLDR: I'm implementing a CQRS + DDD solution for one of my larger projects, and, I'm wondering if there is any real reason that my command handlers can't directly dispatch the command objects to my aggregates, in a small handful of cases, where the command object is data rich? I can't find any specific reason why this would be any kind of an anti-pattern, and I can't find any opinions that go into great detail about this type of design.

背景：我之前已经实现了CQRS系统，并且已经实现了DDD应用程序，但是从来没有在适当的Eric Evans风格的域驱动应用程序中实现过CQRS + DDD。所以我问，因为我不想滥用我的聚合，并且长期伤害我的应用程序。

Background: I have implemented CQRS systems before, and I have implemented DDD applications, but never CQRS + DDD in a proper Eric Evans style domain driven application. So I ask because I don't want to abuse my Aggregates, and hurt my application in the long term.

我的命令对象有大量数据的示例将是一个包含8个以上字段的注册命令（名字，姓氏，首选名称，dob，标题，用户名，密码，部门等）。在我的Aggregate上创建一个具有8个参数的方法感到非常尴尬，而使用某种类型的dto并让我的处理程序将命令映射到dto的替代解决方案-要么自动使用automapper，要么内联-似乎是不必要的，非增值抽象。

An example of my command object having quite a bit of data would be a registration command that takes in 8+ fields (firstname, lastname, preferred name, dob, title, username, password, department etc). It feels very awkward creating a method on my Aggregate that has 8 params, and the alternative solution of using some sort of dto, and having my handler map the command to the dto - either automagically using automapper, or inline - seems like an unnecessary and non value adding abstraction.

我还可以看到将来的用例中命令可能是数据丰富的（命令不会占很大比例，但是仍然会有一些），所以我想从一开始就弄清这个看似微不足道的方面。

I can also see future use cases where commands might be data rich (it wouldn't be a large percentage of commands, but there would still be a few), so I'd like to get this seemingly trivial aspect correct from the start.

推荐答案

通常表示命令对象

您没有立即认识到这一事实，这可能意味着您错过了很多创造机会的机会

The fact that you didn't immediately recognized that probably means that you missed a lot of opportunities to make implicit concepts explicit in your domain.

一个注册命令，需要8个以上的字段（名字，姓氏，
优先） rred名称，dob，标题，用户名，密码，部门等）

"a registration command that takes in 8+ fields (firstname, lastname, preferred name, dob, title, username, password, department etc)"

应该引起注意的是 firstname 和 lastname 肯定可以构成一个有意义的整体，例如 new FullName（firstname，lastname）并且我确定还有很多其他情况，可以或应该在您的域中使用值对象（VO）... 用户名，密码等？使用VO来建模一起变化的事物将更好地描述您的模型，并减少必须传递的参数数量。

What should strike you is that firstname and lastname could definitely form a meaningful whole, such as new FullName(firstname, lastname) and I'm sure there's a lot of other cases where Value Objects (VO) could or should be used in your domain... Username, Password, etc. ? Using VOs to model things that changes together will better describe your model as well as reduce the number of arguments you have to pass around.

因此，这使得命令对象不适合作为候选对象作为聚合方法参数。如果您走这条路，肯定会错过建模的机会。

Therefore, that makes command objects poor candidates as aggregate method arguments. If you go down that road, you will definitely miss modeling opportunities.

这篇关于将CQRS命令直接传递给Domain对象的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！