OpenFeign 的实现归属：调用方（消费者）定义是主流和推荐做法。

在 Spring Cloud 官方文档和绝大多数教程中，OpenFeign 客户端接口（@FeignClient）由调用方实现。服务提供方只需要提供标准的 REST Controller 接口（用 @RestController + Spring MVC 注解），调用方根据提供方的 API 文档（OpenAPI/Swagger）在自己项目中定义 Feign 接口。

示例（调用方代码）：

@FeignClient(name = "user-service", path = "/api/users") public interface UserFeignClient { @GetMapping("/{id}") UserResponse getUser(@PathVariable("id") Long id); }

提供方不需要也不应该在自己的模块里写 @FeignClient（除非是测试桩）。

为什么不是提供方实现？

• 提供方如果把 Feign 接口打包成公共模块供调用方依赖，会导致双向耦合：调用方依赖提供方的接口定义，一旦提供方改接口，所有调用方都要升级。
• Feign 本质是“声明式 HTTP 客户端”，属于调用方的基础设施层，不是提供方的职责。

实际项目常见做法（非严格 DDD）

很多企业项目（尤其是 Java 同构微服务）会采用提供方维护公共 API 模块的模式：

• 提供方建一个 xxx-api 模块，里面放：
  • Feign 接口
  • Request/Response DTO
  • 统一 Result 包装类
• 调用方直接 maven/gradle 依赖这个 api 模块。 优点：避免代码重复、接口一致性强。
  缺点：版本升级麻烦、跨语言不友好、多调用方时维护成本高。

这种做法在 V2EX 等社区讨论中被认为是“TOB 产品化项目”的实用折中方案，但不是最优解。

DDD（领域驱动设计）项目的最佳实践：调用方在防腐层（ACL）中实现 Feign

DDD 强调每个微服务是一个限界上下文（Bounded Context），上下文之间必须保持模型独立（不能共享领域对象）。直接依赖提供方的 DTO 或 Feign 接口会“腐蚀”本上下文的领域模型。

核心原则：

• 服务提供方：只暴露 REST API（最好同时提供 OpenAPI 规范）。
• 调用方：在防腐层（Anti-Corruption Layer，ACL） 中实现所有外部调用。
• Feign 客户端必须放在调用方的 ACL 里，永远由调用方自己定义。

DDD + OpenFeign 推荐分层结构（调用方项目）

调用方微服务 ├── domain/ # 领域层（纯业务模型，不依赖任何外部 DTO） ├── application/ # 应用层 ├── infrastructure/ │ └── acl/ # 防腐层（重点！） │ ├── feign/ # Feign 接口定义 │ ├── adapter/ # 适配器（Feign → Domain Model 转换） │ └── translator/ # 翻译器（DTO 转换） └── interfaces/ # 对外暴露

具体实现模式（推荐）

1. Feign 接口（ACL 内）：

   @FeignClient(name = "order-service") public interface OrderFeignClient { @PostMapping("/orders") ExternalOrderResponse createOrder(ExternalCreateOrderRequest req); }

   注意：这里用的是外部模型（ExternalXXX），不是本领域模型。

2. 适配器/翻译器（核心解耦）：

   @Component public class OrderAclAdapter { private final OrderFeignClient feignClient; public Order createOrder(CreateOrderCommand cmd) { ExternalCreateOrderRequest req = translator.toExternal(cmd); ExternalOrderResponse resp = feignClient.createOrder(req); return translator.toDomain(resp); // 翻译成领域对象 } }

3. 领域层完全隔离：领域服务只看到 Order（本上下文领域对象），不知道外部服务长什么样。

为什么这是 DDD 最佳实践？

• 保护限界上下文：提供方模型变更只影响 ACL 翻译器，本领域模型不受影响（符合“防腐”本意）。
• 上下文映射：属于 DDD 的“客户-供应商”或“遵奉者”关系时用 ACL。
• 可测试性：ACL 可以轻松 mock Feign，实现 Consumer-Driven Contract 测试（Spring Cloud Contract）。
• 跨语言友好：即使提供方是 Go/Python，调用方依然能定义自己的 Feign 接口。

不推荐：提供方直接提供 Feign 接口给调用方（违反 DDD 模型独立性）。

总结对比表

额外建议：

• 始终让提供方输出 OpenAPI 文档，作为 Feign 接口的唯一真相来源。
• 大型项目推荐结合 Spring Cloud Contract 做消费者驱动契约测试。
• 如果调用非常频繁且同语言，可考虑 gRPC + Protobuf（比 Feign 更强类型安全）。

在 DDD 项目中，坚决把 OpenFeign 放在调用方的防腐层，这是保持领域模型纯净、系统长期可演化的关键实践。很多阿里/华为的 DDD 落地案例都是这么做的。