DDD聚合和根聚合创建的有效建模

这是一个不同的视角，可能会让你摆脱僵局。

我觉得你正在做数据建模而不是真正的域建模。您关注的是使用ORM（EF）直接持久化的关系模型，而不太关心实际的问题域。这就是为什么你担心项目会加载太多东西，或者哪些对象会将外键保存到什么东西。

另一种方法是暂时忘记持久性并专注于可能需要什么责任的事情。有责任我不是指保存/加载/搜索等技术问题，而是域定义的东西。就像创建任务，完成任务，添加评论等一样。这应该给你一个大纲，比如：

    
      interface Task {
    …
    void CompleteBy(User user);
    …
}
interface Project {
    …
    Workstream CreateWorkstreamFrom(Template template);
    …
}
</code>
  

团队对这种方法感到不舒服，感觉不对劲。

这是一个非常好的迹象。

但是，根据您只能通过其根引用另一个聚合的原则，这是不可能的。

你会想放下这个想法，它会妨碍你。

简短的回答是标识符不是引用。持有另一个实体的标识符副本是可以的。

更长的答案：DDD基于埃里克埃文斯的工作，埃里克埃文斯正在描述一种在千禧年开始时为他的Java项目工作的风格。

他遇到的痛苦是：如果应用程序允许对象引用

随意

数据实体，然后域的行为最终散布在整个代码库中。这会增加您理解域所需的工作量，并且会增加制作（和测试！）更改的成本。

反应是引入一门学科;通过限制应用程序访问一些精心约束的门守护者（“聚合根”对象）来隔离应用程序中的数据。该应用程序可以容纳

对象引用

到根对象，并且可以向那些根对象发送消息，但是应用程序不能持有引用，或者直接发送消息给隐藏在聚合的api后面的对象。

相反，应用程序向根对象发送消息，然后根对象可以将消息转发给其自己的聚合中的其他实体。

因此，如果我们想要向某个Project内部的Task发送消息，我们需要一些机制来了解

哪一个

要加载的项目，以便我们可以将消息发送到项目以向Task发送消息。

实际上，这意味着你需要一个可以接受TaskId的函数，并返回相应的ProjectId。

最简单的方法是简单地将两个字段存储在一起

    
      {
    taskId: 67890,
    projectId: 12345
}
</code>