domain-driven-design - 在 CQRS/Event sourcing 中，是否所有数据都需要在 Command 和 Events 中？

Question

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

1. 由命令处理程序处理的应用程序调度命令 DTO
2. 在传递和应用命令的数据时聚合引发事件
3. 事件处理程序在收到他们感兴趣的事件时应用领域逻辑和副作用(在我的例子中:他们进行预测)。

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

示例:

• 我有一个员工汇总
• 一个RegisterEmployee命令
• EmployeeRegistered 事件

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

它是Worker Entity 的根，所以在我的应用程序的某处，我有一个员工聚合 ID(UUID，域生成)和 Worker 实体 Id(整数，数据库生成)的映射

命令端:

在 RegisterEmployee 命令中，我是否需要传递混合所有员工字段所需的所有数据？

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

我不能在命令中只提供基本字段(名字、姓氏、电子邮件)并传递工作人员实体 ID，以便 RegisterEmployee 命令处理程序可以在数据库中检索电话和地址字段以传递给聚合吗？

事件方:

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

或者我是否可以只在 EmployeeRegistered 事件的有效负载中放入基本信息(名字、姓氏、电子邮件)和工作人员实体 ID，以便投影脚本自己加入数据库以检索一些复杂和隐藏的信息？

[编辑]

也许 RegisterEmployee 试图做太多事情，我应该:

1. 使用基本内容发送一个简单的 RegisterEmployee 命令
2. 发送一些其他命令，如 AddEmployeeTelephone、AddEmployeeAdrress 等

但在那种情况下，是否违反了注册操作应在同一事务中发生的原则？如果我的 RegisterEmployee 成功而其他人不成功怎么办？我最终会得到一个不完整的员工注册流程吗？

[编辑 2 ]

嗨，Bola，你说对了。我的上下文发生在从遗留应用程序迁移到 cqrs 应用程序(至少某些部分)的过程中。

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

这就是为什么我可以想象有一个命令保存“刚刚保留的”实体 ID，以便不重复命令中的实体字段，并减轻管道。

Answer 1

域模型/设计中出现问题。让我退后一步，概述理想的方式，以便您可以映射缺失的部分。

• RegisterEmployee 命令 包含Employee Aggregate
的所有数据输入
• Employee Application Service 接收来自前端的命令
• Employee Application Service 初始化Employee Aggregate，最好借助工厂方法
• Employee Aggregate 在成功验证和构建新的 Employee 对象时引发 EmployeeRegistered 事件
• Employee Application Service 在 Employee Repository 的帮助下保存新的 Employee 对象
• EmployeeRegistered Event 在持久事务成功后发送到消息代理
• EmployeeRegistered Event 包含订阅者所需的整个数据集
• Subscribers 此事件可以在同一个限界上下文 (BC) 或不同的 BC 中
• Interested Subscribers 捕获事件并在自己的 BC 中调用相关的 Application Service
• 应用程序服务 初始化基础设施服务并执行交易(在您的情况下，这些是预测)

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