DDD中的聚合和UML中的聚合以及组合的关系

UML：

聚合关系：成员对象是总体的一部分，可是成员对象能够脱离总体对象独立存在。
如汽车（Car）与引擎（Engine）、轮胎（Wheel）、车灯（Light）之间的关系为聚合关系，引擎、轮胎、车灯能够脱离车而存在，好比把一个引擎换到另外一个汽车上也能够。

组合关系：也表示的是一种总体和部分的关系，可是在组合关系中总体对象能够控制成员对象的生命周期，一旦总体对象不存在，成员对象也不存在。

因此，UML中聚合与组合的共同点：是二者都是总体与部分的关系，差异点：是总体消亡后，成员对象是否能够脱离总体对象而单独存在。

DDD聚合

也是一种总体和部分的关系，部分脱离总体会变得毫无心义，总体和部分之间强调一致的生命周期，也就是总体消亡的话部分也一块儿消亡，不能单独存在。因此，从定义来看DDD中的聚合应该和UML中的组合关系是同一种关系。因此，Martin Flower也说，DDD中的聚合是限定在DDD这个方法论的上下文中，它不一样于其余上下文（UML）中的聚合。

一个例子

按照上面的定义，咱们再来分析一下一个典型的例子，就是公司和部门的关系。

UML的角度：
一、一个公司由多个部门组成，因此知足总体和部分的关系；
二、一个部门不能脱离公司和加入到其余公司；

因此，咱们推导出，在UML中公司和部门应该属于组合关系。

DDD的角度：
虽然基于UML的角度，公司和部门属于组合关系，那在DDD中是否应该把部门聚合在公司下面呢？个人见解是，虽然从生命周期上，确实部门不能脱离公司。可是DDD的聚合设计要考虑的因素会更加丰满，好比：

• DDD强调需求和Bounded Context，也就是会基于需求和上下文进行建模，咱们建模前必需要先肯定当前的需求和上下文是什么；
• 总体在当前上下文是否强关心部分的存在；
• 总体和部分之间是否存在某些不变性规则；
• 操做总体与操做部分的业务场景是否一致；
• 性能问题，若是总体聚合的部分的数量过大，那也不会考虑聚合，即小聚合原则；
• 一致性问题，咱们在设计系统时，即使把本该是聚合在一块儿的对象分开设计为多个聚合，也能够从技术上去解决一致性，好比经过领域服务来完成多个聚合的协同建立、删除、修改，并能经过数据库事务来保证严格的强一致性；
• DDD领域建模会对领域概念进行抽象，因此再领域模型中，在有些业务系统如组织架构管理系统中，也许就没有公司了，而是只有部门，把公司也当作是一个顶层的部门就行，因此天然就不会有公司这个聚合根了；

因此，在进行DDD聚合设计时，若是仅从总体消亡后部分是否仍然存在乎义这个点去推导的话，那考虑的就太单薄了，颇有可能会得出不合理的聚合设计，最终极可能会致使聚合设计过大。这是没有认真分析业务需求，没有分析业务规则不变性，没有对领域概念进行合理抽象，没有进行OO软件设计原则的应用的表现。

因此，以上案例因为需求不明，没法进行聚合设计。

题外话

我以为DDD是对OOA/D的一个衍生，OOA/D是一种面向对象分析与设计的思想，强调经过设计对象，为对象分配职责，并让对象之间经过协做的方式来完成软件功能。而DDD则是对OO中的对象进行进一步的细化，好比首次提出了聚合、聚合根、实体、值对象、工厂、领域服务、领域事件，等。尤为是聚合的提出，让OO设计更加丰富，大大减小了对象之间的关系复杂度，以及对象之间边界的更加清晰。可是聚合的设计也颇有难度，好比技术人员须要从我上面列举的这些角度（不限于此）去进行聚合分析设计，这对开发人员的能力素质是一个很大的要求，能够说若是不会OOA/D的分析思惟，就很难进行DDD领域建模。因此，我想这也是DDD很难在业务系统中落地的一个很大的缘由之一吧。