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