对于聚集根的成员实体可以指向根实体（不是相反）？
可以吗？假设我有人口AR（人口是根实体，人口成员是成员实体之一）。
我正在评估人口与人口成员之间的关联方向。另一端还有另一个实体，人（自己的AR，人口成员都提及人）。
在ER（数据库）世界中，我们通常会从人口成员身上指出人口（人口_会员是人口与人之间多对多关系的连接表）。
）。，但我认为在DDD世界中，我应该打破这种习惯，并将联系从人口（概念模型）指向人口成员。
无论如何，在此之前，我想确认是否（也许在其他情况下）我们可以将成员实体的关联到根实体。
有什么想法？
好吧，让我们将这个问题分为两个部分：
- 成员实体可以保持其汇总根的引用吗？
- 一般汇总建模规则
让我们从1：
开始否，通常儿童实体不应参考骨根。骨料根是整个聚集体的入口点，必须保持其一致性边界。这意味着，必须通过根实体（通过调用根实体的方法）转发到汇总的每个更改）。总词根可以返回对儿童实体的引用，但它们必须是短暂的。同样，客户不应对根部根部之外的儿童实体进行更改 - 否则可能会违反一致性。考虑到这一点，我真的没有看到儿童实体对其根的参考的原因（从客户的角度来看 - 您已经可以访问根源，不是吗？）。我现在看到的唯一例外是，当您需要将模型转换为某些特定需求时（例如，演示层需要根实体ID才能产生有意义的JSON输出）。但是，即使在这种情况下，您也可能会创建一个单独的读取模型或提供专业的汇编程序来构建所需的DTO。
好，现在到第二点：
看来，您正在尝试像构建数据库模型一样对域实体进行建模。在DDD中，我们应该首先关注模型的业务需求和行为。当构建有意义的域模型时，数据关系并不重要（我们稍后再完善它）。因此，首先，您应该专注于从领域专家那里收集业务情况。聚合应建立在真实的业务不变性的基础上。您应该与团队（包括业务成员）一起创建一个共同的模型。经过几次知识校正会话后，您的设计很可能会完全不同。也许人并不是真正的根源，而只是一个价值对象？也许您甚至不需要人口成员实体？聚合的最常见设计只是一个具有多个值对象的单个（根）实体。此外 - 我经常创建完全独立的数据库模型，几乎没有与域模型的连接（ID除外）。我使用翻译层（映射器组件）在域和lt; -> dbModel之间转换。在我最近的项目中，我的数据库模型与域层极大不同（专门针对持久性层的需求进行了调整 - 因此，使用了许多平坦的属性 - 不是完整的对象，而是简单的原始值）。如果有关系数据库，您甚至可以明确地提供双向关系（实际上，您甚至不需要使用任何ORM）。将数据库模型与域模型分开有很大的优势。设计绝对更柔和。但是，对于简单项目而言，db＆lt; ->域层之间的映射成本（开发人员工作）可能太大了。在这种情况下，我通常从通用模型开始，然后重构为可分离的层。
哦，另一件重要的事情 - 通常只用ID来引用其他骨料根是一个好主意。这样，您就不会在复杂的对象图上遇到问题，也无需担心修改单个事务中的其他聚合物（聚集根不应修改其他根源）。如果您需要在聚合之间进行通信 - 而是使用事件。
请，请参阅沃恩·弗农（Vaughn Vernon）的一系列文章：
http://ddddcommunity.org/library/vernon_2011/
我认为这些文章可以帮助您了解总体建模概念。