欢迎光临汤雪华的博客

一个人一辈子能坚持做好一件事情就够了!坚持是一种刻意的练习,不断寻找缺点突破缺点的过程,而不是重复做某件事情。
posts - 141, comments - 2098, trackbacks - 0, articles - 0
  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

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

Posted on 2019-06-24 17:48 netfocus 阅读(...) 评论(...) 编辑 收藏

UML:

聚合关系:成员对象是整体的一部分,但是成员对象可以脱离整体对象独立存在。
如汽车(Car)与引擎(Engine)、轮胎(Wheel)、车灯(Light)之间的关系为聚合关系,引擎、轮胎、车灯可以脱离车而存在,比如把一个引擎换到另一个汽车上也可以。

组合关系:也表示的是一种整体和部分的关系,但是在组合关系中整体对象可以控制成员对象的生命周期,一旦整体对象不存在,成员对象也不存在。

所以,UML中聚合与组合的共同点:是两者都是整体与部分的关系,差别点:是整体消亡后,成员对象是否可以脱离整体对象而单独存在。

DDD聚合

也是一种整体和部分的关系,部分脱离整体会变得毫无意义,整体和部分之间强调一致的生命周期,也就是整体消亡的话部分也一起消亡,不能单独存在。所以,从定义来看DDD中的聚合应该和UML中的组合关系是同一种关系。所以,Martin Flower也说,DDD中的聚合是限定在DDD这个方法论的上下文中,它不同于其他上下文(UML)中的聚合。

一个例子

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

UML的角度:
1、一个公司由多个部门组成,所以满足整体和部分的关系;
2、一个部门不能脱离公司和加入到其他公司;

所以,我们推导出,在UML中公司和部门应该属于组合关系。

DDD的角度:
虽然基于UML的角度,公司和部门属于组合关系,那在DDD中是否应该把部门聚合在公司下面呢?我的看法是,虽然从生命周期上,确实部门不能脱离公司。但是DDD的聚合设计要考虑的因素会更加丰满,比如:

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

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

所以,以上案例由于需求不明,无法进行聚合设计。

题外话

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