在DDD，CQRS + EventSourcing应用程序的命令中包含实体或dto是否可以？我认为不应该这样做，至少任何实体都不应该成为命令的一部分。
我尝试用语言来描述问题： 我有一个聚合根A，它可以有一个属性实体列表。一个属性实体没有它自己的聚合根，它只是我的聚合根A的一部分。此外，一个且相同的属性实体不能成为另一个聚合根的一部分。
我公司的一些开发人员认为，使用CreateAggregateA命令保存Property-Entity对象列表是一种不错的方法。命令处理程序创建聚合，将所有属性实体添加到列表中并保存聚合。
此外，AggregateACreated事件还具有不正确的属性实体列表。
是否可以将属性实体与域中的propertyDto对象交换（命令和处理程序都在域中）？
或者命令应该总是尽可能地简单。
例如，仅拥有一个仅带有简单类型（字符串名称，字符串otherParameter）的CreateAggregateA命令，而我们需要一个附加命令CreateProperty来创建属性实体并将其添加到链接的集合中？
周围有最佳实践吗？我在Google上搜索了很多，但没有找到明确的声明或指导。
我们非常感谢您的帮助和投入。
关于， 基督徒
答案 0 :(得分：2)
免责声明：我不是DDD专家。我只是分享我所学到的知识和一些个人见解。
在DDD中：
我看到的大多数DDD示例都是在类似六边形的体系结构中实现的，在该体系结构中，命令在主适配器（例如HTTP控制器）中直接实例化和合并，然后传递到应用程序服务或命令总线。
也就是说，在命令中包含实体可能会使您先进行外部数据突变，然后再进行请求和/或逻辑验证。因此，在某些情况下，不能尊重2/。
此外，这样做可能会迫使您在外部数据中提供实体的所有属性，而这并非总是必要的。
DDD将值对象视为域模型的一等公民，并建议使用它们（如果它们对您的模型有意义）：
在DDD + CQRS中，实体尤其处理写入问题，而VO可以用作读取模型。
结论：
在项目中实施DDD可能会使您花费更多的时间进行设计，编写许多具有不同关注点的对象，具有一些冗余代码等。 这可以帮助您处理业务复杂性，并使模型清晰并受到控制：）
如果您的业务简单，不涉及太多风险或不属于核心业务领域，那么尊重DRY并使用实体来解决不同问题的基于CRUD的解决方案也将非常有效。
我希望这会有所帮助