腾挪2023-01-26 来自上海👍第一次看到有人把“聚合”这个概念讲得如此通透，感谢。作者回复: 共同进步 ：）
共 2 条评论6
Ouyang2023-01-06 来自广东ddd聚合的概念，如果用uml图来表示，是不是用组合，也就是实心的菱形更合适？ uml聚合，部分可以脱离整体存在，uml组合，部分不可以脱离整体存在作者回复: 你说得对，本来是这样，但《DDD》原书用错了，如果改过来，命名又会混淆。所以课程里是将错就错的策略。用实心菱形确实更符合UML.
共 3 条评论5
小52023-01-12 来自广东对于不变规则，有个问题请假老师。 业务背景： 系统中有客户，客户下面有一个或者多个联系人 不变规则：同一个客户下面的联系人名称和手机号不能重复 新需求：现在增加一个需求， 需要根据租户的参数设置（是否允许联系人手机号重复）去校验。 如果不允许重复的话就需要校验整个租户下面的联系人手机号不允许重复。 问题：想问下这个根据参数设置动态校验的逻辑是应该写在领域层还是应用层呢？作者回复: 这是一个业务人员关注的规则对吧，只要是这样，就放领域层
共 2 条评论4
quietwater2023-02-28 来自北京老师，对派生关联没有完全理解，能否再详细解释一下这个概念。作者回复: 在我们的例子里，由于项目经理实体（或者考虑项目经理表也行）里有时间段，也有状态，所以完全可以从项目经理实体中得出“当前项目经理”。所以“当前项目经理”那个关联是不必画的。画了以后反而是冗余的。一般而言图里最好不要有冗余。但是，领域专家可能特别关注“当前项目经理”这个概念，所以特别想在图里画出来。这时候，可以画出来，但最好标明，这是一个“派生”出来的关联。
3
Jaising2023-02-03 来自浙江翻了下 《UML和模式应用》 结合钟老师和其他评论——《DDD》 里的聚合用 UML 表示的话就是组合，应该用实心菱形表示，这里就将错就错了。DDD 的聚合具有特点：不能共享，不可游离，级联删除。 迭代一的建模练习现在看来可以进一步优化：比如用户故事与优先级应该是一个以用户故事为聚合根的聚合，因为优先级依赖用户故事存在，属于整体拥有部分这种模型，并且用户故事的优先级具备不变规则特性，并发调整优先级会产生破坏。作者回复: 不错
3
南山2023-01-12 来自江苏客户、合同、项目每个都是一个聚合的判断依据是什么呢？感觉和说的1.整体部分，2.具有不变规则，而且并发时可能被破坏 1.客户与合同、合同与项目是不是也有整体部分的关系，比如合同终止了，项目是不是也就取消或者完成了呢？ 2.划分成独立聚合是考虑没有不变规则吗？ 3.同一个合同也有可能创建多个项目来落地，理论上是不是也可能存不变规则被破坏？作者回复: 这几个问题比较微妙，可以继续探讨，我尝试回答一下。 1.关于整体部分关系，还要看用户的理解，比如，用户是把项目当成一个单独的单元去处理，还是每次都经由合同再去处理项目 2.可以再加强一下，必须是即时保证的，每时每刻都不变的规则。理论上可以用最终一致性处理的，就不算了。 3.理论上有，可以考虑其他方式保证，聚合不是处理不变规则的唯一方式。
3
hk2023-01-05 来自广东老师这课讲的很通透，理论结合实践，至少我学起来少走很多弯路作者回复: 谢谢肯定，咱们共同提高
3
Michael2023-02-14 来自陕西老师说的以聚合作为事务边界保证事务一致性，我理解 - 所有的对聚合的更新或者插入操作只能通过聚合根 - 聚合内部保证强一致性 但是这样并发度是不是降低了？或者应该这样问，老师讲的通过事务和锁来保证数据一致性这个我不太理解，即便我们使用了聚合作为事务边界，但并发场景下，再怎么样也得用乐观锁或者悲观锁来保证数据一致性吧?这个跟是不是聚合好像没什么关系。请老师再展开说说!作者回复: 这节课只讲了聚合的概念，所以您会有这样的疑问。后面两节课应该能回答您的问题，也讲到了乐观锁。
1
escray
2023-01-29 来自北京聚合是为了保护业务规则么？我之前的理解聚合是把相关的实体放在一起。当然，说是为了保护业务规则看上去也不错。 读原文：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. 仅仅依靠数据库的事务机制，估计很难保证保证不变规则，采用事务机制似乎更加不灵活。展开作者回复: 关于仅仅依靠数据库事务不能保证不变规则的问题，后面讲到乐观锁的时候，就清楚了。
1
金山💰2023-06-25 来自广东我总感觉这个技能不能重复那个例子可以用一个数据库的组合唯一索引去做啊作者回复: 是的，后面讲“限定”那节课就会说到。不过，程序应该先守住，数据库的唯一索引是最后的“底线”。