拥有一个大的聚合可能是一个糟糕的聚合设计的标志。聚合是有意义的。它定义了对几个实体的操作的一致性边界，这些实体必须是一致的（集合体中的所有元素都是一致的）。如果它变大了，（以一种极端的方式，一个聚合为您的整个系统！），这意味着你试图保持所有实体之间的一致性。当然，你是在保持整体的一致性，但以加载整个系统数据为代价。要定义实体周围的最佳边界：

• 你应该问问自己，哪些实体需要保持一致性？例如，“学校”在整个操作中强制保持整个聚合一致的不变量是什么？如果“学校”的任何实体不关心其他实体或“学校”，则必须将其从聚合中取出，并在其周围定义另一个聚合。例如，对“course”实体的操作可能不需要检查与“school”相关的不变量。2因此它可能在另一个集合中。
• 你应该让它更小，以加载更小的数据。但不要太小，因为它会受到一致性问题的影响。在这种情况下，你必须考虑最终的一致性和 Saga 等模式，以使其一致（一个更复杂的解决方案）。

一些其他注意事项要记住：

• 不要过早地优化您的解决方案。将您的聚合体设计为坚固且干净。之后，如果您在生产中遇到性能问题，请优化您的解决方案。
• 要设计您的域模型，请考虑这三个概念之间的权衡：

1.域模型完整性
1.域名模型纯度
1.业绩
这里有一个优秀的**article**由弗拉德米尔Khorikov的关于这些概念。

学校实体包含各种聚合实体，如员工、课程、日程流、文档等，从而产生20多个属性。这些属性中的大多数呈现一对多（1-M）关系，有些甚至具有自己的聚合根。
好吧，这是你的问题。聚合根（AR）代表一致性边界，为了使边界清晰，建议只通过ID引用其他AR。在研究Spring Data JDBC之前，我认为你应该回顾一下如何design proper aggregates由行为和业务不变式驱动。
聚合设计并不是对所有实体关系进行建模，而是将评估业务不变式（必须始终保持高度一致和有效的规则）以及结果状态转换所需的数据聚集在一起。
有时，当使所有规则都强一致是不切实际的（例如，性能差，并发冲突太多等），那么我们可能需要找到一种方法来使一些规则最终一致，并分解更大的集群。

如果你希望你的School模型总是有效的，因为每个Course都有老师，老师是分配给它的学校Staff的一部分，那么基本上总是需要加载你的所有模型来检查这些不变量。
但这种情况很少发生，更好的解决方案是允许这样的问题显式地存在于模型中（可能作为他们自己的实体）。这样用户就可以评估不同的选项并修复它们。（您可能正在使用的IDE在告诉您另一个文件中的编译错误时会执行类似的工作，但不会阻止你继续编辑当前打开的文件。MS Word也是如此，它会让你知道在当前光标位置上方3行的单词中有一个错字，但你仍然可以继续键入。