DDD 中的聚合根应该怎么理解？

[isakbener256]

目前项目中有这么一个需求：
用户可以创建比赛，比赛里面有很多轮小比赛，每一轮小比赛中有几个分组，用户可以在分组中报名。

[DreamStar]

写了不少, 写累了. 转成一段话.
用 OOP 的范式参考 DDD 战术策略 把 与领域(业务)专家沟通的专业知识和专用词语构建成的统一语言模型 转换 为近似自然语言的用例和代码即可.
领域事件是帮你模拟自然的, 有助于解耦和拆解大事务.(其实最终一致性才是大多数, 真正必须的强一致还是少的)
CQRS 是帮你解决写核心业务时强行兼容查询模型带来的冲突.
写领域模型时不要考虑表结构, 要优先考虑模型结构, 在最后持久化时实在调和不了的按需调整模型.
跟领域专家不要提技术相关词语, 用跟领域专家能听懂的模型语言沟通, DDD 最核心的在于技术跟业务同用一套模型语言沟通与交流.
----
在上下文中将所有实体组合成的超级聚合的最顶级实体就是聚合根, 你的所有业务方法都以聚合根为入口.
例如参赛者(选手)报名参赛, 将其分配到竞赛第一赛程的某一个竞赛组中.你将通过竞赛对象上的一个添加参赛者的方法把这个选手通过内部赛程,竞赛组的相关方法记录进去.

这个超级聚合是不可取的, 因为聚合要保证一致性, 会有剧烈的并发冲突. 加载时也要全部加载, 浪费资源.
要根据实际情况的生命周期和最小一致性来拆分.
例如竞赛和赛程在超级聚合中是组合关系, 现在拆成聚合关系, 即仅记录所有赛程的 id(当然也可以记录部分摘要信息, 也可以只记录当前赛程的 id), 看业务而定. 如果记录摘要, 当赛程更新是发出事件, 竞赛监听赛程更改事件更新摘要, 而不是在更新赛程的事务中同时更新摘要!

每次事务只更改一个聚合, 跨聚合更改用事件来做最终一致性.
当然一定要跟领域(业务)专家沟通好.