我可以使用一些帮助来理解我的域模型，并确保我正确地接近设计。
我有一个名为Department的聚合根。 Department对象有几个子值类型，有助于定义“部门”的业务概念。在我的UI中，用户可以列出，创建，编辑和删除部门对象。
我有另一个名为Project的聚合根。项目有几种子值类型，但与部门有关系，因为每个项目都由一个部门“拥有”。可以创建，编辑，删除项目等，这样做对部门没有影响，而删除部门也会删除它拥有的任何项目。
我的UI将根据当前用户有权访问的部门显示项目列表。他们可能能够访问多个部门。当同时显示列表项目和详细信息时，我需要在项目中显示部门徽标。
我首先想到的是Project是一个聚合根，它有一个简单的DepartmentID属性，可用于“查找”部门。但现在我开始认为我真的只有一个聚合根：部门。
您怎么看？
更新
我不知道这是讨论的关键还是改变了什么，但在阅读了前几个答案后，我发现了以下想法。
部门似乎有两种情况：
这让我觉得我的模型中应该有两个'对象'，一个是＃1的聚合根，另一个是＃2的值类型。我是在正确的轨道上吗？
答案 0 :(得分：1)
由于项目在没有部门的情况下不能存在，因此它可能不是聚合根。根据您的描述，听起来您只有一个AR - 部门，您用它来管理其中的项目。
如果你的行为主要是CRUD，我不建议为它构建一个完整的域模型，因为你可以采取更简单的方法。
<强>更新 如你所述，你可能在这里有2个有界的上下文。一个部门是AR，而项目是AR的实体。在此上下文中，您将对您的部门执行操作。在第二个BC中，您的项目可以是AR，而部门可以是实体或VO。这将允许您直接使用项目。
我还建议您与您的领域专家一起讨论这个问题，看看这些概念是否适合您的UL，或者可能会搜索一些可以澄清您的模型的缺失概念。我特别想找一个可能将项目链接到部门的概念。
答案 1 :(得分：1)
我认为将项目和部门都作为集合根源是完全可靠的，因为它们都是独立管理的。
也就是说，每个项目和每个部门都有某种唯一标识符，虽然您可以将项目添加到部门，但项目本身可能足够复杂（有自己的生命周期，自己的子对象等）以保证聚合根状态。
您只需要在每个项目中保留对部门的引用。
答案 2 :(得分：0)
很少有简单的问题需要回答：
1）部门域对象可以在没有Project域对象的情况下自行生存。 - 如果是，则该部门是一个聚合。
2）Project域对象是否可以独立存在 - 如果是，那么Project也是一个聚合
3）项目是否与一个部门有关系 - 然后它应该是作为财产部门公开的项目集合的一部分
4）部门是否与一个或多个项目对象有关系 - 项目聚合应该是部门聚合对象的一部分。
因此，使用Department聚合对象，您可能需要访问Project（s）对象列表，一旦拥有Project对象，您可能需要访问Department对象。这是一个过时的精细循环参考。
这是一个典型的例子，员工有经理，经理有员工名单