Domain driven design 使用领域驱动设计建模一对多关系

这个问题更像是一个关于如何使用集合对简单的一对多关系建模的一般性问题：列表项中的更改是否应该反映在包含它的聚合版本中

该域与会议计划有关（与Outlook中类似）。 我有一个会议实体，可以有多个参与者。 参与者可以接受/拒绝会议请求。 重新安排会议将取消所有参与者的确认

我想到了两种建模方法

选项1 会议汇总将包含参与者列表，其中每个参与者都有一个参与者ID和一个状态（接受/拒绝）。 这里的问题是，对于特定的参与者，每个接受或拒绝命令都会增加会议的版本，这意味着如果两个参与者试图基于相同的原始版本接受会议请求，则将进入竞赛条件。 虽然这可以通过重新阅读会议文档并重试Accept命令来解决，但考虑到这种情况发生的频率，这是相当烦人的。 另一种方法是在执行Accept命令时忽略会议的版本，但这引入了一个新问题：如果在发送会议请求后会议被重新安排，会发生什么情况？在这种情况下，我们不能忽视会议的版本，因为这次的版本确实代表了一个应该考虑的真实版本。 顺便问一下，忽略某些命令中的版本而不忽略其他命令中的版本是否是一种好的做法

选项2 从会议中提取一个参与汇总。 参与将具有MeetingId、ParticipanID和状态。 它也将有自己的版本。 这样，当参与者X接受会议请求时，只有相关的参与者将被修改，其余的将保持不变。 并且，在重新安排会议时，将发布“会议重新安排”事件，事件处理程序将通过将所有参与者的状态重置为“NotAccepted”（未接受），而不管其当前版本如何。 一方面，这听起来合乎逻辑，因为会议的版本不应该仅仅因为有人接受/拒绝其请求而增加。 另一方面，将参与建模为一个独立的聚合对我来说不太合适，因为它在会议的上下文之外没有任何意义

无论如何，我很想得到反馈，看看解决这个问题的各种方法

虽然这可以通过重新阅读会议文档并重试Accept命令来解决，但考虑到这种情况发生的频率，这是相当烦人的

这看起来像是一个建模错误。您应该记住，会议总量并不是参与者可用性的记录簿，而是真实世界。所以消息不应该是AcceptInvestment，而应该是InvitationAccepted。这不应该有冲突，因为域模型不能否决其权限边界之外的事件

根据您的实现，您可能会在管道中出现并发修改异常，但这是您应该自动处理的事情（即：预期的任何版本，或重试）

另一种方法是在执行Accept命令时忽略会议的版本，但这引入了一个新问题：如果在发送会议请求后会议被重新安排，会发生什么情况

这里的解决方案是更仔细地建模。是的，有时您会收到一条消息，接受或拒绝已过期的邀请

换句话说：

时间上的微秒差异不应该对核心业务行为产生影响

当会议重新安排时，立即回复邀请的爱丽丝会怎么样？为什么鲍勃在会议重新安排后收到回复时，不会发生同样的事情呢

作为一个独立的集合参与对我来说并不太合适，因为它在会议之外没有任何意义

我发现启发式并不是特别有效。更重要的是要了解实体是否可以独立地更改状态，或者它们的更改是否需要协调

实际上，会议聚合用于跟踪参与者的可用性。这就是它的目的。除非我没有完全理解你

这有点微妙，我说得不太清楚

假设模型上说我有空，但现实世界中的紧急情况却叫我离开。会发生什么？我不能去医院是因为模特说我必须去开会吗？有人可以通过更改我提交的邀请来取消我的紧急情况吗

此外，如果我因紧急情况外出，您是否可以参加与您和我将要举行的会议时间相同的会议

在这个空间里，真实世界是决定某人是否可用的权威。该模型只是查看一条消息的缓存副本，描述过去是否有人可用

模型使用的缓存信息不保证完整。见格雷格·杨

这让我想到，也许会议聚合应该有两个版本字段：一个是一个强版本，当递增时，表示一个突破性的更改，另一个是用于非突破性更改的软版本。这有什么意义吗

不是真的。据我所知，这个版本并不是一个取自无处不在的会议日程语言的术语。它是元数据，如果它存在的话，模型中的业务规则不应该依赖于元数据

我同意，但会议ID（或任何与此相关的ID）也不是ubiqui的一部分