王杰岸接手过不下二十个微服务拆分项目，我几乎每次都会被问到同一个问题：“Feign接口到底该放哪儿？是domain层吗？”问的人多了，我意识到这不是个例，而是很多团队在落地DDD时，对OpenFeign的定位都有共同的困惑。有人把Feign客户端直接塞进domain层，结果领域模型被网络细节污染得面目全非；有人把Feign接口撒在infrastructure层，结果多个防腐层各写各的，接口重复得一塌糊涂。
这篇文章，我就按DDD领域分析OpenFeign这条主线，把自己实际项目中的分层经验、接口归属决策、以及那些文档里不会写明白的坑，一次性讲透。
1. 先搞清楚：OpenFeign在DDD分层里到底算什么
1.1 技术组件化与领域对象的边界
很多文章一上来就讲DDD四层架构怎么分层、OpenFeign放哪一层，但如果你不理解“技术组件”和“领域对象”的本质区别，分到哪都是错的。
在DDD的视角里，OpenFeign是一个纯粹的技术组件，它做的事情是“把一次Java方法调用翻译成一次HTTP请求”。这件事本身没有任何业务含义，就像你用MyBatis做数据库查询一样，它只是完成数据进出的一种手段。而领域模型关心的是“订单是什么”“库存怎么扣”，它不关心你调用远程服务时用的是HTTP还是Dubbo，更不关心你的连接池是Apache HttpClient还是OkHttp。
所以，OpenFeign在DDD架构中的定位，应该和数据库访问组件是同类：它属于基础设施层（Infrastructure）的技术实现细节。我在实际项目中遵循的约束是：domain层绝对不能出现@FeignClient注解，那里只能有纯Java的领域模型和业务规则。否则一旦哪天要把Feign换成别的通信方式，你连领域层都要跟着动，这就不叫领域驱动了，这叫通信方式驱动。
1.2 一个典型的微服务DDD落地结构
先给大家看一个我目前正在维护的订单系统的项目结构，这个结构经过了多个项目的迭代验证，比较稳妥：
code复制order-service/
├── order-interface/ # 对外暴露的Feign接口定义
│ └── api/
│ └── OrderFeignClient.java
├── order-application/ # 应用服务层
├── order-domain/ # 领域层
│ ├── model/
│ ├── service/
│ └── repository/
├── order-infrastructure/ # 基础设施层
│ ├── feign/
│ │ └── UserFeignClient.java
│ └── repository/
注意看，这里分成了两个方向：order-interface模块里放的Feign接口，是提供给“别人调我”用的；order-infrastructure/feign里放的Feign接口，是我作为消费者“调别人”用的。很多团队不分这两个方向，所有Feign客户端堆在一个包下，时间一长就开始乱，这是后话，这里先记住这个结构差异。
1.3 为什么说Feign是接入防腐层的最佳载体
DDD里有个概念叫防腐层（Anti-Corruption Layer，ACL），它的核心作用是：隔离外部上下文的模型，防止外部概念的“腐蚀”渗透到自己的领域模型里。
OpenFeign天然适合做防腐层的载体。为什么？因为Feign把远程调用封装成了一个本地接口调用，你在自己的应用里面对的是一个定义好的Java接口，而HTTP协议的复杂性被完全隐藏了。这就意味着，你可以在infrastructure层实现一个防腐层类，内部依赖Feign客户端，向外部暴露一个符合自己领域语言的方法。
我举个具体例子：在订单服务里，我需要查用户信息。用户服务的返回模型里有几十个字段，包括userId、userName、phone、email、address、tags、score等等。但订单领域真正关心的只有userId和userName。如果我直接在application层去调Feign接口拿完整的用户DTO，那么领域层就被迫知道了用户服务的完整模型，这不合理。
正确做法是：在infrastructure层定义一个UserRepository接口的实现类，它内部持有UserFeignClient，把远程返回的UserDTO转换成领域层需要的UserName值对象或者一个轻量化的UserBrief模型。这样领域层看到的永远是自己的语言，而不是别人家的字典。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。