根实体对另一个根的引用答案

【问题标题】：Root Entity reference to another root根实体对另一个根的引用
【发布时间】：2011-05-25 06:38:03
【问题描述】：

我面临一个典型的 DDD 问题。它必须非常基础。我有订单和客户。一个客户可以创建多个订单。客户是其自身聚合的根。秩序是其自身聚合的根。但是当客户创建订单时，我们会在订单上显示部分客户信息。 Order 聚合是否应该保留对客户的引用？当它持有它时，当订单存储库获得订单时，我们也能够检索客户信息的某些部分以进行显示。但是，当我们在交易中涉及订单时，客户也会参与其中，如果客户也同时得到更新，就会产生问题。请各位大侠指教！我的直觉告诉我，我不能从订单中引用客户。

问题 2：（新）

我能否在创建订单（使用订单工厂）时获取并保存给定订单的客户参考（来自客户存储库）并安全地保存订单（无论如何都不更新客户，客户只是为了信息/查询？）如果同一客户在其他地方被修改，则不会产生争用？让我们假设 NHibernate 为 ORM。

【问题讨论】：

标签： domain-driven-design

【解决方案1】：

一个简单的答案是您持有客户的 ID，或者，如果您的域需要一些带有客户信息（ID、名称）的最少的 ValueObject。

一个更复杂的答案是考虑限界上下文。请参阅Eric Evans's presentation，他希望他将 BC 章节作为本书的第一章。

这个想法是，在您的客户管理有界上下文中，您的客户实体可以是客户聚合的 AR，而订单可以是客户聚合中的实体。在 Billing Bounded Context 中，您可以拥有一个带有 Customer 实体的 Order AR。

【讨论】：

你谢谢。如果我采用最简单的方法，我是否仍然可以设置从 Order 到 Customer 的表级引用外键约束，即确保如果我在表级删除客户，我必须确保相应的 Orders 也被删除。
您可以这样做，但如果它是您域中的有效业务案例，我建议您在域级别而不是数据库级别处理。
如果没有关联的订单，则删除客户是数据库级别的一项工作，每隔“X”年就会发生一次，以修剪不再活跃的客户的客户表。它不是这样的 UI 操作。甚至订单在完成其生命周期后每年都会被删除。我还需要继续使用复杂的方法来分离有界上下文吗？同时我认为我需要在表级别施加外键约束以保持检查:) 请告知。
谈到分离有界上下文的复杂方法，就像您所说的客户管理有界上下文，客户实体可以是客户聚合的 AR，订单可以是客户聚合中的实体。我们如何确保并发的 Hibernate 会话不会抛出错误；一个会话作用于客户（比如客户更新他的个人资料），另一个会话是审批人同时编辑客户的订单？