从DDD视角设计API端点的困惑：REST与领域驱动适配问题

先分清查询和命令的区别 #

• 查询操作：完全不用纠结DDD的聚合根约束，直接按REST资源逻辑来就行。比如要查某个学生的信息，直接用/students/:studentId，因为查询只是读取数据，不会改动领域状态，不需要遵守聚合根的一致性规则。
• 命令操作（修改数据）：这时候必须严格遵循DDD的聚合根规则。比如给学生分配辅导教师、调整教师名下的学生名单这类操作，得走/teachers/:teacherId/students/:studentId，通过教师聚合根来执行，确保业务规则（比如教师最多能带多少学生、是否具备执教权限）被正确校验。

拆分学生资源的属性边界 #

• 把学生的属性分成两类：一类是自身独立的（比如姓名、学号、出生日期），这类属性的修改不需要依赖教师的业务逻辑，那学生本身就可以作为独立聚合根，直接用/students/:studentId来修改；另一类是和强关联的（比如所属辅导教师、教师分配的专属任务），这些操作必须通过教师聚合根来完成，走嵌套端点。
• 别硬把所有操作都绑定到教师聚合根上，先梳理清楚业务规则：如果学生的某些修改和教师完全无关，那它就该成为自己的聚合根。

用动作端点解决特殊场景 #

• 有些跨聚合的操作，或者用REST标准方法（GET/POST/PUT/DELETE）无法清晰表达的命令，可以设计动作端点。比如要给学生分配教师，不用非得嵌套在教师路径下，而是做/students/:studentId/assign-teacher，通过POST请求把教师ID传进去，内部还是调用教师聚合根的assignStudent方法，既符合REST的直观性，又不违反DDD的约束。

避免过度复杂的嵌套路径 #

• 如果嵌套层级太深（比如/teachers/:id/classes/:cid/students/:sid），反而增加使用成本，可以简化成/students/:sid/assign-to-teacher，把教师ID放到请求体中传递，既减少URL的复杂度，又能保证命令通过聚合根执行。

内容的提问来源于stack exchange，提问作者Jay-flow