DDD领域驱动设计批评文集>>
《软件方法》强化自测题集>>
《软件方法》各章合集>>
有一个地方想和您商榷，这张图上说对象树是译者的臆想，我觉得译者译成对象树也对，因为聚合根和其他对象是一对多关系，您觉得呢？
如果组合（聚合）关联的整体一端的多重性上限为1，也就是说，部分对象在同一时间最多只属于一个整体对象，那么这个整体-部分的对象链接结构确实是一棵有向树。例如，图1左侧的类图就可能得到右侧形状的对象图（树）。
如果一个部分对象可以属于多个整体对象（实际上这时整体-部分的含义已经模糊），那就是一张有向无环图，如图2。
这意味着组合（聚合）是非对称的：如果对象B是对象A的部分，那么对象A不能直接或间接成为对象B的部分。“间接”背后的意思是：组合（聚合）是传递的，如果对象B是对象A的部分，对象C是对象B的部分，那么，对象C是对象A的部分。像图3是不允许的。C是B的部分，B是A的部分，也就意味着C间接是A的部分，那就不允许A同时也是C的部分。
“对象树”有道理是不是意味着“译者译成对象树也对”？这个倒要好好说一说。原文用词是graph of … objects（对象图），是不是译者像您（提问者）这样，想到了这一点，站得高看得远，然后毅然出手纠正作者，把译文改为“对象树”呢？我们把这段译文一句一句仔细看看就知道了，看看译者（以及审校者）的水平是不是有三四层楼那么高。Is an Aggregate
just a way to cluster a graph of closely related objects under a common parent?聚合只是将一些共享父类、密切关联的对象聚集成一个对象树吗？原文只是说under a common parent，“共享”属于译者自由发挥。译者可能搞混了类和对象，搞混了集合和个体，看到原文的parent，误以为是“父类”（其实是整体对象），从而臆想出“共享父类”、“一个（应为一棵）对象树”的译文。说“共享父类的类”或“类的对象”或“共享父类的类的对象”都可以，但不应说“共享父类的对象”。“共享父类的类”的类图（不考虑多继承）如图4左侧的树，但是这棵树是“类（集合）”的树，不是“对象（个体）”的树。对象关系是像图4右侧这样的。
以人举例，“共享父类的类的对象”是由若干“中国男人”对象、“美国女人”对象……组成的集合，它们的类的父类都是“人”。
读者可以自行体会"人有男有女"、"人有手有脚"、“人有车有房”、“人有高富帅有屌丝”的区别。
当然，作者此处用parent一词欠考虑，但还是尽量尊重原文，parent可译为“父对象”。“关联”一般指association，association一词在面向对象中有特定含义，组合（聚合）就是一种特殊的关联。在问题所给图片中可以看到，在本句之后就有association出现，“can the associations be
navigated……”，作者在这里用词还是很准确的。这个看起来像是个小问题，无非是译者用词比较随意，但并非如此。Aggregate的各个部件之间只是相关（related），并不需要存在关联（association）。
手、眼、心、肝这些部件和整体对象存在关联（组合关联），但它们之间并不需要存在关联，像图6这样：
注意：我的用词是“不需要存在”。如果你要是执意要像图6这样做，也不是不可以，只不过是一个不良结构。可能有的开发人员会想，图6有道理呀，这些部件之间有“兄弟”或“同事”关联呀！其实这些“兄弟”或“同事”是从整体-部分关联推算出来的冗余概念，系统不需要维护。怎么个相关？静态上，它们都是人的部件，动态上，它们在某个场景中由整体对象协调来完成任务，如图7：
*注意：可能某些部件并不需要参与某个场景，也就是说，图5中某些类的对象不一定出现在图7中（当然，可能会出现在其他场景中）。这个知识点，评点后面几句译文时还会再提到。聚合只是把在共同父对象之下紧密相关的对象图聚集在一起的一种方式吗？