正在用 DDD 开发，请问在划分 aggregate 时候，遇到一些多对多的中间表该怎么处理？

[289396212]

把这些中间实体单独作为一个 aggregate 吗？

[dcdlove]

通过领域事件来协调多对多关系的更新。例如，当一个 Student 注册到一个 Course 时，可以发布一个 StudentRegisteredForCourse 事件，其他聚合可以订阅这个事件并更新自己的状态。

[289396212]

@dcdlove 所以中间表还是存在的吗？只是原本是直接拿到这个中间实体的 repo 来增加一个 Student 和 Course 的 row, 变成了从领域事件里来增加这个 Student 和 Course 的 row ？

[alcoholpad]

“把这些中间实体单独作为一个 aggregate 吗？”
这个要根据实际业务情况来分析的，如果这个中间实体没有独立的业务场景，只是关联关系的话，不需要单独作为聚合根。 但如果它有独立的业务场景和生命周期，就需要单独作为一个聚合根，比如说学生和课程这个 “选课” 中间关系，选课需要审批流程（独立业务场景）、选课要求不随着学生或课程的不存在而消失（独立的生命周期）等。

[2han9wen71an]

我一般中间表要落库就弄聚合，不过我也是半吊子哈

[YuuuuuuH]

多对多里面一定有业务，你得提取它的业务概念出来。比如 Student 和 Course 的多对多关系，可以提取出 [选课] （ CourseEnrollment ）的业务概念。DDD 一定要提取业务概念！ DDD 一定要提取业务概念！ DDD 一定要提取业务概念！

[AcFnu]

领域设计就不要表设计先行了，分析问题的时候只关心领域业务，先把你问题域分析好了，就拿上面学生和课程的例子来说，学生和课程理论上都要单独作为聚合根的，此时学生与课程的关联关系是要单独处一个 Vec<Student>和 Vec<Course>的业务聚合根（或者更多你的业务）用来处理学生和课程多对多的领域问题，然后正常就走 route-》 cmd-》 handler-》 aggregate-》 event-》至于监听事件后的 repo 你关系行数据库就正常该怎么关联存就怎么存

[WispZhan]

@AcFnu +1

业务层是业务层，持久层是持久层。 既然是 DDD ，就不要搞普通的三层了。嫌多、嫌麻烦就不用 DDD 。