CQRS - 从一个表单生成多个命令
CQRS - Generate multiple commands from one form
我遇到了一个问题，不知道该怎么办。
我的域名：
我有一个 Booking 实体，它是 booking 业务上下文 的根。
在 Booking 中存在 Event(s) 的集合，这是用户创建的真实事件的列表。 Booking看起来有点没用，但是整个系统将Booking链接到其他实体，所以它确实是业务的根源。
Event 可以有文本注释，因此我创建了一个 Notes 实体。我使用实体是因为笔记可能会随时更改，它们链接到 Event 并且无法共享。 Notes 实际上绑定在 booking 业务上下文 中并聚合到 Booking 根实体。
表单（创建事件）：
我有一个用于提交 "Events" 的表格。实际上，表单的数据生成一个命令，其中包含创建新 Event 所需的所有信息，如果用户需要，它的 Notes .
命令（创建事件）：
从表单创建命令并将其发送到服务器。该命令具有事件的数据。
服务器上的处理程序对主要实体 Booking 进行操作，创建一个新的 Event。根据用户在表单中输入的内容，Event 可能有或没有 Notes。
预订业务上下文处理的其他命令是：
- 删除事件
- 取消一个事件（为不能发生的事件创建一个特殊事件），将来它也可以用来添加一个注释（为什么事件被取消）
- 为取消的活动创建备份活动
实际上在此上下文中的另一个命令是
- 更新事件注释
我的问题来了：
无需处理 Event 即可更改，是否可以将 Notes 提升为根实体并使其成为业务上下文？因此，我最终会为 Bookings 和 Notes.
提供一个上下文
实际上，要更改 Notes 并留在 DDD 上下文中，因此不要暴露太多，我必须做一些 "jumps" 来执行更改。它有效，是的，但它很丑。如果我拆分这些东西，也许它会更优雅，并且与正确的上下文相关。
另一方面，如果答案是 yes，我如何处理第一个命令，它生成 Event 注释？同样的问题也适用于取消。
我无法从表单中触发两个命令，一个依赖于另一个，因此顺序很重要。
也很难创建一个处理程序（最后一个事件侦听器），在 create/cancel 成功完成后，它会触发第二个命令来更改 Notes。如何识别正确的 Event？必须使用表单发送的数据创建侦听器，以匹配要处理的事件。
Inside the Booking exist the collection of Event(s), that is the list
of real events created by the user. Booking looks a bit useless, but
the whole system links the Booking to other entities, so it's really
the root of the business.
据我了解，没有 Booking aggregate root 必须保护的不变量。即使 Event 属于 Booking，如果没有规则规定不应存在某些事件组合，那么 Event 也应该是 Aggregate root.
因此，CreateEventCommand 应包含 BookingId、EventId 和可选的 notes。
Notes actually are bound inside the booking business context and
aggregated to the Booking root entity
我不太同意这一点。笔记属于 Event 而 Event 属于 Booking 所以 Note 被 link 编辑为 Booking 是正常的，但是没有 link a Note 到 Booking 的不变量，只有 ID 的关联在任何情况下都是 DDD 允许的。
could Notes be promoted as root entities and have they're business context?
是的，如果没有必须由 Event AR 保护的不变量。那么，CreateNewNoteCommand 应该包含 BookingId 和 EventId.
It's also hard to create an handler (a event listener, at the end)
that, after the create/cancel are successfully completed, it fires a
second command to change the Notes. How can I identify the right
Event? The listener must be created with the data sent by the form, to
match the event to handle.
确实，设计给你的反馈是你做错了。如果你的 Aggregates 设计得当，这种情况就不会发生。如果事情看起来变得非常复杂，那么请返回并重新考虑您的设计。 DDD 主要是关于重构。
我遇到了一个问题，不知道该怎么办。
我的域名：
我有一个 Booking 实体，它是 booking 业务上下文 的根。
在 Booking 中存在 Event(s) 的集合，这是用户创建的真实事件的列表。 Booking看起来有点没用，但是整个系统将Booking链接到其他实体，所以它确实是业务的根源。
Event 可以有文本注释，因此我创建了一个 Notes 实体。我使用实体是因为笔记可能会随时更改，它们链接到 Event 并且无法共享。 Notes 实际上绑定在 booking 业务上下文 中并聚合到 Booking 根实体。
表单（创建事件）：
我有一个用于提交 "Events" 的表格。实际上，表单的数据生成一个命令，其中包含创建新 Event 所需的所有信息，如果用户需要，它的 Notes .
命令（创建事件）：
从表单创建命令并将其发送到服务器。该命令具有事件的数据。
服务器上的处理程序对主要实体 Booking 进行操作，创建一个新的 Event。根据用户在表单中输入的内容，Event 可能有或没有 Notes。
预订业务上下文处理的其他命令是：
- 删除事件
- 取消一个事件（为不能发生的事件创建一个特殊事件），将来它也可以用来添加一个注释（为什么事件被取消）
- 为取消的活动创建备份活动
实际上在此上下文中的另一个命令是
- 更新事件注释
我的问题来了：
无需处理 Event 即可更改，是否可以将 Notes 提升为根实体并使其成为业务上下文？因此，我最终会为 Bookings 和 Notes.
提供一个上下文
实际上，要更改 Notes 并留在 DDD 上下文中，因此不要暴露太多，我必须做一些 "jumps" 来执行更改。它有效，是的，但它很丑。如果我拆分这些东西，也许它会更优雅，并且与正确的上下文相关。
另一方面，如果答案是 yes，我如何处理第一个命令，它生成 Event 注释？同样的问题也适用于取消。
我无法从表单中触发两个命令，一个依赖于另一个，因此顺序很重要。
也很难创建一个处理程序（最后一个事件侦听器），在 create/cancel 成功完成后，它会触发第二个命令来更改 Notes。如何识别正确的 Event？必须使用表单发送的数据创建侦听器，以匹配要处理的事件。
Inside the Booking exist the collection of Event(s), that is the list of real events created by the user. Booking looks a bit useless, but the whole system links the Booking to other entities, so it's really the root of the business.
据我了解，没有 Booking aggregate root 必须保护的不变量。即使 Event 属于 Booking，如果没有规则规定不应存在某些事件组合，那么 Event 也应该是 Aggregate root.
因此，CreateEventCommand 应包含 BookingId、EventId 和可选的 notes。
Notes actually are bound inside the booking business context and aggregated to the Booking root entity
我不太同意这一点。笔记属于 Event 而 Event 属于 Booking 所以 Note 被 link 编辑为 Booking 是正常的，但是没有 link a Note 到 Booking 的不变量，只有 ID 的关联在任何情况下都是 DDD 允许的。
could Notes be promoted as root entities and have they're business context?
是的，如果没有必须由 Event AR 保护的不变量。那么，CreateNewNoteCommand 应该包含 BookingId 和 EventId.
It's also hard to create an handler (a event listener, at the end) that, after the create/cancel are successfully completed, it fires a second command to change the Notes. How can I identify the right Event? The listener must be created with the data sent by the form, to match the event to handle.
确实，设计给你的反馈是你做错了。如果你的 Aggregates 设计得当，这种情况就不会发生。如果事情看起来变得非常复杂，那么请返回并重新考虑您的设计。 DDD 主要是关于重构。