仅使用名词无动词的REST API搭配DDD的利弊及标准解决方案问询

目前行业尚未出台官方强制的统一标准，但已经形成了多个经过大规模业务验证的成熟实践，可根据团队场景灵活选择：

• 名词化行为子路径方案（当前最通用的折中选择）
  将DDD领域模型的行为名词化，作为对应聚合根资源的子路径进行接口设计，既不违背REST的资源核心设计原则，也能直接映射到领域方法，无需额外复杂适配。
  比如要调用订单聚合的cancel()取消方法，可设计接口为POST /orders/{orderId}/cancellation，方法入参直接放在POST请求体中即可。
• 命令资源独立建模方案（适合复杂CQRS+DDD场景）
  将每个领域命令直接建模为独立的资源，完全对齐DDD的命令驱动设计，无需关心操作对应的聚合根归属，适配多聚合协作的复杂业务场景。
  比如要执行用户地址变更的领域行为，可设计接口为POST /address-change-commands，请求体直接承载命令所需的全量参数，接口层无需额外逻辑即可直接转换为领域层的命令对象。
• 薄防腐层适配方案（适合强制要求纯名词REST规范的场景）
  如果团队或对接方有严格的纯名词REST规范要求，禁止接口路径出现行为相关标识，可在接口层实现极薄的防腐层做适配：通过PATCH请求体中的操作标识字段，映射到对应的领域方法即可。
  比如调用PATCH /users/{userId}时，根据请求体中的op字段判断要执行的行为，op: "bindPhone"就映射调用user.bindPhone()方法，op: "resetPassword"就映射调用user.resetPassword()方法，适配逻辑简单，不会带来过多额外开发成本。

至于你提到的在API路径中直接引入动词的实践（比如Twitter API的POST /statuses/update），本身没有本质缺陷，所谓的细节问题大多来源于团队没有统一的命名规则导致的维护成本，只要内部约定好规范完全可以直接使用，无需为了贴合REST纯粹主义的要求额外增加不必要的开发成本。

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