14|聚合的概念:怎样保护业务规则?
聚合的概念
- 深入了解
- 翻译
- 解释
- 总结
领域驱动设计(DDD)中的聚合模式是本文的重点内容。文章首先介绍了聚合的概念和重要特征,以员工的工作经验和技能建模为例,阐述了聚合的作用。接着,通过UML图形式清晰地展示了聚合根、整体部分关系等概念,并讨论了聚合的表示法。文章强调了聚合在并发环境下保护业务规则的必要性,并引出了后续课程将讲解的具体实现方法。进一步探讨了聚合的基本特征和推论,包括部分实体只能属于一个聚合根、聚合根被删除则整个聚合的实体都会被删除等。此外,还探讨了聚合的作用,如提供了一个新的视角来讨论业务规则、联系业务规则和事务、增加模型的清晰度等。最后,提出了两个思考题,引发读者对不变规则的保护和数据库事务机制的思考。整体而言,本文深入浅出地介绍了聚合的概念和领域建模,为读者提供了对DDD中聚合模式的全面了解。
《手把手教你落地 DDD》,新⼈⾸单¥59
全部留言(28)
- 最新
- 精选
- 腾挪👍第一次看到有人把“聚合”这个概念讲得如此通透,感谢。
作者回复: 共同进步 :)
2023-01-26归属地:上海210 - Ouyangddd聚合的概念,如果用uml图来表示,是不是用组合,也就是实心的菱形更合适? uml聚合,部分可以脱离整体存在,uml组合,部分不可以脱离整体存在
作者回复: 你说得对,本来是这样,但《DDD》原书用错了,如果改过来,命名又会混淆。所以课程里是将错就错的策略。用实心菱形确实更符合UML.
2023-01-06归属地:广东39 - 小5对于不变规则,有个问题请假老师。 业务背景: 系统中有客户,客户下面有一个或者多个联系人 不变规则:同一个客户下面的联系人名称和手机号不能重复 新需求:现在增加一个需求, 需要根据租户的参数设置(是否允许联系人手机号重复)去校验。 如果不允许重复的话就需要校验整个租户下面的联系人手机号不允许重复。 问题:想问下这个根据参数设置动态校验的逻辑是应该写在领域层还是应用层呢?
作者回复: 这是一个业务人员关注的规则对吧,只要是这样,就放领域层
2023-01-12归属地:广东24 - hk老师这课讲的很通透,理论结合实践,至少我学起来少走很多弯路
作者回复: 谢谢肯定,咱们共同提高
2023-01-05归属地:广东4 - quietwater老师,对派生关联没有完全理解,能否再详细解释一下这个概念。
作者回复: 在我们的例子里,由于项目经理实体(或者考虑项目经理表也行)里有时间段,也有状态,所以完全可以从项目经理实体中得出“当前项目经理”。所以“当前项目经理”那个关联是不必画的。画了以后反而是冗余的。一般而言图里最好不要有冗余。但是,领域专家可能特别关注“当前项目经理”这个概念,所以特别想在图里画出来。这时候,可以画出来,但最好标明,这是一个“派生”出来的关联。
2023-02-28归属地:北京3 - Jaising翻了下 《UML和模式应用》 结合钟老师和其他评论——《DDD》 里的聚合用 UML 表示的话就是组合,应该用实心菱形表示,这里就将错就错了。DDD 的聚合具有特点:不能共享,不可游离,级联删除。 迭代一的建模练习现在看来可以进一步优化:比如用户故事与优先级应该是一个以用户故事为聚合根的聚合,因为优先级依赖用户故事存在,属于整体拥有部分这种模型,并且用户故事的优先级具备不变规则特性,并发调整优先级会产生破坏。
作者回复: 不错
2023-02-03归属地:浙江3 - 南山客户、合同、项目每个都是一个聚合的判断依据是什么呢?感觉和说的1.整体部分,2.具有不变规则,而且并发时可能被破坏 1.客户与合同、合同与项目是不是也有整体部分的关系,比如合同终止了,项目是不是也就取消或者完成了呢? 2.划分成独立聚合是考虑没有不变规则吗? 3.同一个合同也有可能创建多个项目来落地,理论上是不是也可能存不变规则被破坏?
作者回复: 这几个问题比较微妙,可以继续探讨,我尝试回答一下。 1.关于整体部分关系,还要看用户的理解,比如,用户是把项目当成一个单独的单元去处理,还是每次都经由合同再去处理项目 2.可以再加强一下,必须是即时保证的,每时每刻都不变的规则。理论上可以用最终一致性处理的,就不算了。 3.理论上有,可以考虑其他方式保证,聚合不是处理不变规则的唯一方式。
2023-01-12归属地:江苏3 - Geek4329员工和技能应该是多对多关系吧?
作者回复: 当你这么问的时候,你所说的“技能”实际上是模型图中的“技能类别”,请仔细区分。
2023-10-19归属地:上海1 - Michael老师说的以聚合作为事务边界保证事务一致性,我理解 - 所有的对聚合的更新或者插入操作只能通过聚合根 - 聚合内部保证强一致性 但是这样并发度是不是降低了?或者应该这样问,老师讲的通过事务和锁来保证数据一致性这个我不太理解,即便我们使用了聚合作为事务边界,但并发场景下,再怎么样也得用乐观锁或者悲观锁来保证数据一致性吧?这个跟是不是聚合好像没什么关系。请老师再展开说说!
作者回复: 这节课只讲了聚合的概念,所以您会有这样的疑问。后面两节课应该能回答您的问题,也讲到了乐观锁。
2023-02-14归属地:陕西1 - escray聚合是为了保护业务规则么?我之前的理解聚合是把相关的实体放在一起。当然,说是为了保护业务规则看上去也不错。 读原文:AGGREGATES tighten up the model itself by defining clear ownership and boundaries, avoiding a chaotic, tangled web of objects. An AGGREGATES is a cluster of associated objects that we treat as a unit for the purpose of data changes. 印象里面之前的聚合(根)似乎是从面向对象分析或者是业务分析的时候抽取出来的。 聚合是 DDD 中的一个模式,这个是我以前没有注意到的,还有其他两个模式分别是:FACTORIES 和 REPOSITORIES。 对于思考题, 1. 之前并没有将 DDD 落实到具体的项目中,(不变的)规则一般会放到对象实体中去,或者变成配置文件的一部分,应该是缺乏保护,另外修改起来也不方便。 2. 仅仅依靠数据库的事务机制,估计很难保证保证不变规则,采用事务机制似乎更加不灵活。
作者回复: 关于仅仅依靠数据库事务不能保证不变规则的问题,后面讲到乐观锁的时候,就清楚了。
2023-01-29归属地:北京1