domain-driven-design - 将 CQRS 命令直接传递给域对象

Question

~TLDR:我正在为我的一个大型项目实现 CQRS + DDD 解决方案，并且我想知道是否有任何真正的原因是我的命令处理程序不能直接将命令对象分派(dispatch)到我的聚合中，在一个小的少数情况下，命令对象的数据丰富？我找不到任何具体原因说明这会是一种反模式，我也找不到任何关于这种设计的非常详细的意见。

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

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

我还可以看到 future 的用例，其中命令可能是数据丰富的(命令不会占很大比例，但仍然会有一些)，所以我想从一开始就纠正这个看似微不足道的方面。

Answer 1

命令对象通常以原始类型表示，而聚合方法签名将以域概念表示。

您没有立即意识到这一点的事实可能意味着您错过了很多在您的领域中明确表达隐含概念的机会。

"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)... Username , Password ， ETC。 ？使用 VO 对一起变化的事物进行建模将更好地描述您的模型，并减少您必须传递的参数数量。

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