采用DDD模式设计微服务API时新增Estate的接口路径选择问题

两个方案没有绝对的对错，核心判断标准是「单用户最多持有5套房产」这个业务规则的所属域： #

优先选方案1 /user_domain/{user_id}/addNewEstate 的场景 #

如果「用户可持有房产数量」属于用户域的核心权益规则，比如用户会员等级、实名认证状态直接决定可持有上限，规则迭代由用户域的产品逻辑管控：

• 完全符合聚合根作为业务操作入口的规则：该操作本质是触发「给指定用户新增所属资产」的用户域业务动作，所有关联的用户侧规则校验都可以在用户聚合根内完成，避免规则泄露
• 耦合度更低：用户域校验通过后，只需要异步发送「用户新增房产申请」的领域事件给房产域，房产域监听事件完成实体创建和持久化即可，两个上下文不需要强依赖实时调用
• 业务语义和权限校验更直接：从API路径就能明确操作的业务归属，同时可以直接在用户域完成请求人身份校验，避免非本人操作的越权请求

优先选方案2 /estate_domain/addnewEstate?userId=sampleId 的场景 #

如果「用户最多持有5套房产」属于房产域的通用管控规则，比如是房产备案、交易侧的统一限制，和用户域的权益体系无关：

• 符合限界上下文的职责划分：房产本身是房产域的聚合根，房产创建的核心业务逻辑（信息合法性校验、持有数量限制、备案规则校验）本来就应该收敛在房产域内部，不需要把房产域的规则耦合到用户域
• 可用性更高：仅需要在房产创建前调用用户域的开放接口做用户存在性校验，该校验属于弱依赖，可通过缓存用户合法身份做降级处理，不会因为用户域故障影响房产域的核心操作
• 接口职责更单一：后续房产的修改、转让、注销等全生命周期操作都可以收敛在房产域的API前缀下，不需要重复走用户域入口，维护成本更低

通用注意事项 #

• 不要硬套「Estate管理必须通过UserAggregate执行」的规则：聚合根的入口约束是单限界上下文内部的规则，跨上下文操作只需要遵守上下文映射约定即可，不要把A上下文的规则强加到B上下文的实体操作上
• 无论选哪个方案，都禁止跨上下文直接操作数据库，所有跨上下文交互只能走开放接口调用或者领域事件异步同步，保证两个上下文可以独立演进

内容的提问来源于stack exchange，提问作者bwylegly