DDD 每个实体似乎都适合一个聚合
DDD Every Entitys seems fit inside one aggregate
我正在实施一个大学系统，我正在尝试使用 DDD。我也在看蓝皮书。该系统的基本实体是机构、课程、教授和学生。这个系统将允许很多机构，每个机构都有自己的课程、学生和教授。
阅读聚合，所有实体都适合聚合机构，因为没有机构就没有课程，学生和教授也一样。我这样想对吗？
在某些地方，教授将访问他们教授的课程。使用这种方法，我是否应该始终通过机构访问课程？这个实现对我来说似乎很奇怪，所以我问自己，Professor, as Students 是否应该是他们自己的 AR 并拥有他们的 Repository。
教授和学生可以独立存在，实际上他们可能与机构有联系。一个机构以其自身的权利存在。一门课程可能独立存在（如果同一门课程在多个机构提供，它们是否相同？）......领域专家最好就此提出建议（事实上，他们应该建议和指导整个设计） .
如果聚合太大，您将 运行 遇到并发问题，如果您找到合适的模型，这些问题是可以避免的。
我推荐阅读的一些 PDF 在这里：
可能会帮助您将这些实体分成不同的聚合根的一个问题是：必须一起使用其中的哪一个？这通常有助于作为第一个粗过滤器。
因此，例如，要将学生添加到课程中，您不需要机构？
在您的示例中，一位教授访问了他教授的课程。他可以通过提供他的教授 ID 而不是教授实体来访问它们吗？如果他提供了教授 ID，那么实体将不会通过引用关联，而是通过 ID 关联。
自 12 年前编写蓝皮书以来，许多概念已经发生了很大变化。虽然蓝皮书是一本很好的书，但我建议你也看看红皮书(Implementing Domain-Driven Design by Vaughn Vernon)。这本书对 DDD 有更实用的方法，并展示了更现代的方法，例如 CQRS 和事件溯源。
即使你已经接受了一个答案，我还是要加上这个，因为评论太短了。
在开始使用 DDD 时，几乎每个人都会遇到这整个聚合根业务问题。我知道，因为我自己去过那里:)
如前所述，领域专家在某些情况下可能会有所帮助，但请记住，所有权并不意味着遏制。 Order 通常 属于 到 Customer 但 Customer 不是 Order 的 AR，因为 Order可以在没有 Customer 的情况下存在。你可能会想："But wait, that isn't really true!"。这就是归结为规则的地方。当我走进一家服装店时，我可以买一双鞋。我是客户，但除了我可以出示的收据外，他们没有我的任何记录。我是 现金 客户。也许我的特定品牌的鞋子没有存货，但我仍然可以订购。一旦它到达，他们会联系我，这可能就是那样，我很可能仍然没有在任何计算机系统中注册。但是，同一家商店在其供应商处注册为 Customer。
那么为什么要讲这个冗长的故事呢？好吧，如果有可能让一个实体独立，只有一个代表 owner 的值对象，那么它可能会成为一个 AR。我可以在 Order 的 CustomerDetails 值对象中包含一些基本客户信息吗？所以 Order 可以是 AR。
不，我们来看一个OrderLine。我可以在 OrderLine 上包含一些基本的 OrderDetails 信息吗？这感觉很奇怪，因为许多订单行构成了 Order。所以它不是那么自然。
以同样的方式 GrapeBunch 有 有一个 GrapeStem 和一个 GrapeBerry 对象的集合。
这似乎暗示，如果任何东西都可以被视为可选的，则可能表明相关实例是一个AR。但是，如果需要相关实例，则它是 AR 的一部分。
这些想法非常广泛，但可以作为考虑您的结构的指南。
还有一点要记住，一个 AR 不应该在另一个 AR 中实例化。而是使用表示关系的 Id 或值对象。
我认为您遗漏了一些交易分析 - 作为同一业务交易的一部分，什么通常一起变化，变化的频率如何？如果只有 2 个用户协作，并且每天仅进行少量更改，那么一个大聚合不一定是问题，但如果同时进行数十个修改，它可能会成为一个争论点。
除了问题的数据清单和数据结构方面，您还想了解系统将如何用于做出有根据的聚合设计决策。
我正在实施一个大学系统，我正在尝试使用 DDD。我也在看蓝皮书。该系统的基本实体是机构、课程、教授和学生。这个系统将允许很多机构，每个机构都有自己的课程、学生和教授。
阅读聚合，所有实体都适合聚合机构，因为没有机构就没有课程，学生和教授也一样。我这样想对吗？
在某些地方，教授将访问他们教授的课程。使用这种方法，我是否应该始终通过机构访问课程？这个实现对我来说似乎很奇怪，所以我问自己，Professor, as Students 是否应该是他们自己的 AR 并拥有他们的 Repository。
教授和学生可以独立存在，实际上他们可能与机构有联系。一个机构以其自身的权利存在。一门课程可能独立存在（如果同一门课程在多个机构提供，它们是否相同？）......领域专家最好就此提出建议（事实上，他们应该建议和指导整个设计） .
如果聚合太大，您将 运行 遇到并发问题，如果您找到合适的模型，这些问题是可以避免的。
我推荐阅读的一些 PDF 在这里：
可能会帮助您将这些实体分成不同的聚合根的一个问题是：必须一起使用其中的哪一个？这通常有助于作为第一个粗过滤器。
因此，例如，要将学生添加到课程中，您不需要机构？
在您的示例中，一位教授访问了他教授的课程。他可以通过提供他的教授 ID 而不是教授实体来访问它们吗？如果他提供了教授 ID，那么实体将不会通过引用关联，而是通过 ID 关联。
自 12 年前编写蓝皮书以来，许多概念已经发生了很大变化。虽然蓝皮书是一本很好的书，但我建议你也看看红皮书(Implementing Domain-Driven Design by Vaughn Vernon)。这本书对 DDD 有更实用的方法，并展示了更现代的方法，例如 CQRS 和事件溯源。
即使你已经接受了一个答案，我还是要加上这个，因为评论太短了。
在开始使用 DDD 时，几乎每个人都会遇到这整个聚合根业务问题。我知道，因为我自己去过那里:)
如前所述，领域专家在某些情况下可能会有所帮助，但请记住，所有权并不意味着遏制。 Order 通常 属于 到 Customer 但 Customer 不是 Order 的 AR，因为 Order可以在没有 Customer 的情况下存在。你可能会想："But wait, that isn't really true!"。这就是归结为规则的地方。当我走进一家服装店时，我可以买一双鞋。我是客户，但除了我可以出示的收据外，他们没有我的任何记录。我是 现金 客户。也许我的特定品牌的鞋子没有存货，但我仍然可以订购。一旦它到达，他们会联系我，这可能就是那样，我很可能仍然没有在任何计算机系统中注册。但是，同一家商店在其供应商处注册为 Customer。
那么为什么要讲这个冗长的故事呢？好吧，如果有可能让一个实体独立，只有一个代表 owner 的值对象，那么它可能会成为一个 AR。我可以在 Order 的 CustomerDetails 值对象中包含一些基本客户信息吗？所以 Order 可以是 AR。
不，我们来看一个OrderLine。我可以在 OrderLine 上包含一些基本的 OrderDetails 信息吗？这感觉很奇怪，因为许多订单行构成了 Order。所以它不是那么自然。
以同样的方式 GrapeBunch 有 有一个 GrapeStem 和一个 GrapeBerry 对象的集合。
这似乎暗示，如果任何东西都可以被视为可选的，则可能表明相关实例是一个AR。但是，如果需要相关实例，则它是 AR 的一部分。
这些想法非常广泛，但可以作为考虑您的结构的指南。
还有一点要记住，一个 AR 不应该在另一个 AR 中实例化。而是使用表示关系的 Id 或值对象。
我认为您遗漏了一些交易分析 - 作为同一业务交易的一部分，什么通常一起变化，变化的频率如何？如果只有 2 个用户协作，并且每天仅进行少量更改，那么一个大聚合不一定是问题，但如果同时进行数十个修改，它可能会成为一个争论点。
除了问题的数据清单和数据结构方面，您还想了解系统将如何用于做出有根据的聚合设计决策。