Domain driven design 在CQRS/事件源中，是否所有数据都需要在命令和事件中？

假设我有一个围绕CQRS事件源的基础构建的应用程序：

应用程序调度命令由命令处理程序处理的DTO

在传递和应用命令的数据时聚合引发事件

事件处理程序在接收到他们感兴趣的事件时应用域逻辑和副作用（在我的例子中：它们进行投影）

我的问题是：在步骤1和3中，我们是否需要在命令和事件DTO中提供所有信息，或者我们是否可以传递处理程序可以从数据库中获取的某些实体的ID

示例：

• 我有一个员工总数
• 一个registereemployee命令
• 员工登记的事件

员工聚合有名字、姓氏、电子邮件和一些VO，如地址、电话等

它是工作者实体的根，因此在我的应用程序的某个地方，我有一个雇员聚合Id（UUID，生成的域）和工作者实体Id（整数，生成的数据库）的映射

命令端：

在registereemployee命令中，是否需要传递所有员工字段所需的所有数据

然后我会有一个非常大的构造函数，名字，姓氏，电子邮件，地址，电话1，电话2等等

我不能在命令中只提供基本字段（firstname、lastname、email）并传递工作者实体ID，以便RegisterEmployee命令处理程序可以在数据库中检索要传递给聚合的电话和地址字段吗

事件端：

在事件方面，如果我的EmployeeRegistered事件处理程序必须投影我的员工的readmodel，那么它是否需要拥有事件本身中的所有信息来构建readmodel

或者我可以只将基本信息（firstname、lastname、email）和Worker实体ID放入EmployeeRegistered事件的有效负载中，以便投影脚本本身加入数据库以检索一些复杂和隐藏的信息吗

[编辑]

也许注册员工试图做太多的事情，我应该：

发送一个简单的RegisterEmployee命令，其中包含基本内容

发送一些其他命令，如AddEmployeeTelephone、addemployeeadress等

但在这种情况下，它是否打破了注册操作应在同一交易中发生的原则？如果我的注册员工成功了而其他人没有成功呢？我会以一个不完整的员工注册流程结束

[编辑2]

嗨，波拉，你指对了。我的上下文发生在从遗留应用程序迁移到cqrs应用程序（至少部分）的过程中

因此，由于我想让遗留应用程序自己做事情，我只监听数据库端的持久性事件，并从中发送域命令

---

这就是为什么我可以想象有一个命令保存“just persistend”实体id，以避免在命令中复制实体的字段，并减轻管道。

域模型/设计中出现了一些问题。让我退一步，勾勒出理想的方式，以便您可以绘制缺失的片段

• registereemployee命令

  包含员工聚合的所有数据输入

• 员工应用程序服务

  从前端接收命令

• 员工应用程序服务

  初始化

  员工聚合

  ，最好借助工厂方法

• Employee Aggregate

  在成功验证和构造新员工对象时引发

  EmployeeRegistered事件

• Employee应用程序服务

  在

  Employee Repository

• EmployeeRegistered事件

  在持久性事务成功后被调度到MessageBroker

• EmployeeRegistered事件

  包含订阅者所需的整个数据集

• 此事件的订户

  可能位于同一个有界上下文（BC）或不同的BC中

• 感兴趣的订阅者

  在他们自己的BC中捕捉事件并呼叫相关的

  应用程序服务

• 应用程序服务

  初始化基础架构服务并执行事务（在您的情况下，这些是预测）

---

事件处理程序中不应该有域逻辑。

您能澄清一下吗：我不能只在命令中提供基本字段（firstname、lastname、email）并传递工作者实体ID，以便RegisterEmployee命令处理程序可以在数据库中检索要传递给聚合的电话和地址字段吗？-假设您是第一次注册员工（比如说从某种形式上），所有关于员工的数据都应该作为表单数据来提供。否？您将从哪个数据库获取数据？评论不错，缺少一些信息。我编辑了我的问题。