我遇到了一个问题，我不知道该怎么做。
我的域名：
我是一个预订实体，预订业务环境的根。
预订内部存在事件的集合，即用户创建的真实事件列表。 预订看起来有点无用，但整个系统将预订链接到其他实体，因此它确实是业务的根本。
活动可以包含文字说明，因此我创建了 Notes 实体。我使用实体是因为笔记可能会在时间上发生变化，它们会链接到事件并且无法共享。 注释实际上绑定在预订业务环境中，并汇总到预订根实体。
表格（创建活动）：
我是一个用于提交＆＃34;活动＆＃34;的表格。实际上，表单的数据会生成一个命令，其中包含创建新事件所需的所有信息，如果用户需要，还会生成注释。
命令（创建事件）：
从表单中创建命令并将其发送到服务器。该命令包含事件的数据
服务器上的处理程序在主实体预订上运行，创建新的事件。根据用户在表单中添加的内容，事件可能包含注释。
预订业务环境处理的其他命令是：
另一个命令，实际上在这个上下文中，是
我的问题出现了：
如果能够在不必处理事件的情况下进行更改，注释是否可以作为根实体进行宣传并让他们拥有业务背景？因此，我最终会为预订创建一个上下文，为 Notes 创建一个上下文。
实际上，要改变音符并保持在DDD环境中，因此不要暴露太多，我要做一些＆＃34;跳跃＆＃34;执行更改。这是有效的，是的，但它很难看。如果我拆分东西，也许它会更加优雅，并且与正确的背景有关。
另一方面，如果答案是是，我该如何处理第一个命令，该命令会使用注释生成事件 ？同样的问题适用于取消 我无法从表单中触发两个命令，一个取决于另一个命令，因此序列很重要 在创建/取消成功完成后，它会触发第二个命令来更改 Notes ，这也很难创建一个处理程序（最后是一个事件监听器）。如何识别正确的事件？必须使用表单发送的数据创建侦听器，以匹配要处理的事件。
答案 0 :(得分：1)
预订中存在Event（s）的集合，即列表 用户创建的真实事件。预订看起来有点无用，但是 整个系统将预订链接到其他实体，所以它确实如此 业务的根源。
据我所知，Booking aggregate root必须保护的不变量不存在。即使Event属于Booking，如果没有规则说明某些事件组合不应存在，那么Event也应该是Aggregate root。
因此，CreateEventCommand应包含BookingId，EventId和可选的notes。
实际上，注释绑定在预订业务环境中 汇总到预订根实体
我不太同意这一点。 Notes属于Event而Event属于Booking，因此Note链接到Booking是正常的，但没有不变量将Note与Booking相关联，仅ID的关联DDD在任何情况下都允许。
可以将Notes作为根实体进行宣传，并将它们作为业务背景吗？
是的，如果没有必须受Event AR保护的不变量。然后，CreateNewNoteCommand应包含BookingId和EventId。
创建处理程序（最后是事件监听器）也很困难 在创建/取消成功完成后，它会触发一个 第二个命令来更改Notes。我怎样才能找到合适的人选 事件？必须使用表单发送的数据创建侦听器 匹配要处理的事件。
确实，这个设计给了你一个反馈，说你做错了。如果您将Aggregates设计为正确，则不应出现这种情况。如果事情看起来变得非常复杂，那就回去重新思考你的设计吧。 DDD非常重构。