domain-driven-design - DDD - 执行需要了解多个聚合根的规则

Question

我是 DDD 的新手，目前正在寻找通过一些概念证明开始重建现有应用程序，同时我仍在寻找使用 DDD 的方法。我在这里的问题只涉及域模型的一小部分，因此目前看来可能过于简单。

这是一个为在家里探望病人的护士的日程安排应用程序。因此，很明显“Patient”是一个 AggregateRoot，而“Nurse”是另一个 AggregateRoot。除了护士被分配使用“约会”实体探望患者之外，患者与护士没有直接联系。

现在，预约实体可以很容易地属于患者或护士 AR，或者甚至两者都将预约视为两者之间的链接。因此，我还将约会变成了 AR。所以第一个问题是:

1)这个模型听起来对吗？我最初试图在患者/护士 AR 下添加一组约会实体，但由于它确实属于两者，因此成为自己的 AR 是有道理的。然后我想在护士/患者 AR 下添加一个约会 ID 列表以链接到他们的约会，但这意味着保存约会的交易需要同时影响多个 AR，据我所知，这表明一个糟糕的聚合设计。

假设到目前为止这种建模是有意义的，我现在需要找出强制执行涉及当前所有 3 个 AR 的业务规则的最佳方法。例如，一名护士不能同时在多个地方，因此我们不能与分配给同一护士的另一名护士同时创建预约。每个患者也只能有一个待处理的预约。所以第二个问题是:

2)您将如何执行这些涉及多个不同 AR 的规则？显然，如果约会是患者或护士 AR 下的嵌套集合，则规则很容易执行，并且非常独立。这让我怀疑我的建模是否正确。

我已经阅读了很多关于 BC 和 Saga 的/流程管理器，但对我来说，这都是同一个 BC 的一部分，所以不确定我需要任何复杂的东西。简单地拥有一个加载多个 AR 对象并使用它们的状态来确定是否可以创建约会的 CommandHandler 是否可以接受？

如果是这样，并与上面的 Q1 联系起来(假设我没有在护士/患者 AR 下存储预约 ID 列表)，读取模型是轻松找到属于相应护士/患者的预约的唯一方法 -那么基于读取模型的状态而不是存储库中的 AR 来强制执行业务规则是否也可以接受？

希望这是有道理的，并提前致谢!

Answer 1

Does this modelling sound right?

不(但这不是你的错——文学很烂)。你的聚合将是信息的表示，而不是在现实世界中走来走去的人。轮换时间表，值类名单，这些都是可以汇总的东西。

例如:

a nurse can't be in more than one place at once, so we can't create an appointment at the same time as another one assigned to the same nurse

这不是对护士的限制，而是对时间表的限制。

“上午 9 点，护士 (id:12345) 将访问患者 (id:67890)”是一个时间表条目。将所有计划条目一起管理是非常直接的。日程表的 View 可能还需要包括有关护士或患者的附加信息，因此 View 可能会加入附加信息。

该计划成为它自己的“聚合”，使用相关 ID 来启用与其他信息的连接。

Would the schedule be a "NurseSchedule" or a system-wide "Schedule"?

这可能是调度护士用例的特定内容。根据域的不同，给定的时间表可能会涉及许多护士和患者。