企业官网建设流程全解析

1. OpenFeign在DDD四层架构中的真实位置：基础设施，不是领域能力

1.1 一个典型的“伪DDD”案例

先说个我见过很多次的场景。团队花了三周做事件风暴，墙上贴满了彩色便签，白板上画出了漂亮的限界上下文地图。代码结构也按照DDD经典分层搭好了：interfaces、application、domain、infrastructure，连包名都起得规规矩矩。然后你随手点开一个应用服务类，看到的是这样的代码：

@Service @RequiredArgsConstructor public class OrderApplicationService { private final UserFeignClient userFeignClient; private final OrderRepository orderRepository; @Transactional public void createOrder(Long userId, List<OrderItemDTO> items) { UserDTO user = userFeignClient.getUser(userId); if (!"ACTIVE".equals(user.getStatus())) { throw new IllegalStateException("User not active"); } Order order = Order.create(new UserId(user.getId()), items); orderRepository.save(order); } }

这个例子几乎涵盖了所有典型问题：远程客户端的DTO直接穿透到应用层，领域规则（用户状态校验）被写在应用服务里，跨上下文的协作完全绕过了领域模型，OpenFeign的注解和远程数据结构成了业务代码的一部分。

这套代码能跑，也能上线，但它离DDD所说的“领域模型驱动设计”差了十万八千里。问题不在OpenFeign本身，而在你把它放在了架构的哪个位置。这就像一把螺丝刀本身没有错，错的是你拿它去撬钉子。

1.2 从分层架构推导OpenFeign的归属

DDD经典四层架构里，各层的依赖方向是单向向内的：interfaces依赖application，application依赖domain，domain不依赖任何外层，infrastructure为其他层提供技术支撑。在这个模型里，OpenFeign这样的远程调用客户端，本质上是infrastructure层的一种技术实现手段，它和数据库Repository、消息队列Producer是同一类东西——都是“让领域模型得以运转的外围设备”。

你可以这样理解：如果领域层里的一个聚合根要持久化，你不会让聚合根直接操作JdbcTemplate，而是定义一个Repository接口，由infrastructure层去实现。远程调用也是一样。当订单聚合需要获取用户信息时，领域层不应该直接看到UserFeignClient、UserDTO、FeignException这些技术概念，它应该看到的是一份“用户资料网关”的契约：

// domain/gateway/UserGateway.java public interface UserGateway { UserProfile getProfile(UserId userId); }

领域层只关心“我能拿到一个用户的档案”这件事，至于是通过OpenFeign、gRPC还是REST调用，那是infrastructure层的事。这样设计之后，领域模型对技术框架的依赖彻底被切断，你可以随时把OpenFeign替换成别的实现而不影响领域逻辑。这种“端口与适配器”的思路，正是防腐层设计在远程调用场景下的具体落地。

1.3 防腐层不该只是接口套壳

很多人以为在领域层加一个接口、在infrastructure层用Feign实现，就算做完防腐了。这是另一个极端：形式做到了，语义上没有。

防腐层的核心使命是“翻译”，不是“转发”。它要把外部限界上下文里的通用语言，翻译成本限界上下文里的通用语言，同时把技术噪音挡在领域之外。举个最直观的例子：用户服务返回的是一个扁平的UserDTO，字段叫userId、userName、userStatus；但你的订单上下文里需要的是一个UserProfile值对象，它有自己的业务约束和命名习惯。如果防腐层只是原样把UserDTO传进领域层，那你实际建立的不是防腐蚀层，而是一条数据传输管道的延长线。

// infrastructure/gateway/UserGatewayImpl.java @Component @RequiredArgsConstructor public class UserGatewayImpl implements UserGateway { private final UserFeignClient userFeignClient; private final UserDtoMapper userDtoMapper; @Override public UserProfile getProfile(UserId userId) { UserDTO dto = userFeignClient.getUser(userId.getValue()); return userDtoMapper.toDomain(dto); } }

这里的UserDtoMapper承担的就是翻译工作：它把远程服务的字段结构映射成领域模型需要的结构，把远程服务的状态枚举翻译成领域认识的状态枚举，把远程DTO的扁平结构重新组装成具有业务含义的对象。这套翻译逻辑还可以承载数据校验、默认值填充、历史字段兼容等杂活。

要判断你的防腐层是否合格，有一个很简单的标准：把领域层代码里所有import语句扫一遍，如果出现了feign、okhttp、apache.http这类包名，说明防腐层已经有缺口了。

1.4 限界上下文视角下的FeignClient命名与隔离

还有一个经常被忽略的点：FeignClient在代码里如何命名和组织，其实反映了你对限界上下文的认知。

见过不少项目把所有FeignClient堆在一个叫client或者remote的包里，命名是GetUserClient、CreateOrderClient、SendMessageClient，完全看不出服务之间的领域关系。这种做法的本质问题是没有把限界上下文作为组织代码的第一原则。

我的习惯是：FeignClient放在infrastructure层，但按照“对外部上下文的适配器”来归类。比如订单服务里，用户上下文的远程调用放infrastructure/context/user/，库存上下文的放infrastructure/context/inventory/。每个上下文一个子包，包里包含Feign接口、DTO、Mapper、Gateway实现。这样当你打开代码库时，看到的不是一堆散落的HTTP客户端，而是一张“订单上下文需要与哪些邻居协作”的地图。

如果需要访问同一Kubernetes集群下不同命名空间的服务，OpenFeign的配置也要在设计阶段就想清楚。可以通过name加上完整的主机名，比如name = "user-service"，url = "http://user-service.user-namespace.svc.cluster.local:8080"，或者利用Spring Cloud的服务发现配置来区分。关键是在防腐层内部封装这些差异，不要让不同的服务地址暴露在领域层和应用层的业务代码里。

2. 事件风暴推导出的边界：哪些协作该用OpenFeign，哪些该发事件

2.1 事件风暴如何帮你识别“同步请求”该不该存在

很多团队做事件风暴，最后只产出几张限界上下文图和一堆聚合定义，就认为建模完成。其实事件风暴最有价值的产出之一，恰恰是服务之间的协作方式——哪些交互必须同步等待结果，哪些交互适合异步解耦。

在事件风暴的过程中，你会把业务场景拆成一个个领域事件：订单已提交、库存已锁定、支付已完成、通知已发送。每个事件都有触发它的命令，每个命令都由某个聚合承担。这时候你自然要问一个问题：当这个命令执行时，它是否需要立刻知道其他限界上下文的某个信息？

这个问题的答案，直接决定了你是用OpenFeign同步调用，还是发一个异步事件。

举个例子，订单服务里创建订单这个用例，拆解下来会发现它需要校验用户状态、锁定库存、记录订单、发送通知。真实需求是：用户校验必须实时（否则订单可能创建不合法），库存锁定必须实时（否则超卖），但通知发送不需要阻塞主流程。于是协作方式就清楚了：用户校验和库存锁定走OpenFeign同步调用，通知走消息事件异步处理。这不是技术偏好，而是业务需求推导出来的架构决策。

2.2 判断同步与异步的四个标准

我在不同项目里反复使用下面这套标准来判断一个跨服务交互该用OpenFeign还是该用事件，每次建模现场都能把讨论收敛得很快：

这套标准不能反过来用。如果某个交互其实不要求实时，但你硬用OpenFeign去调，结果就是两个服务被强耦合在一起，下游一抖动，上游跟着挂，网络不稳定时链路雪崩。这不是OpenFeign的错，是协作模式选错了。

还有一个常见的认知误区：不要把“一个服务能不能调另一个服务”当作设计依据，而要问“这笔业务在领域层面对协作延时的预期是什么”。这两个视角一个从技术拓扑出发，一个从业务本质出发，设计出来的架构完全不同。

2.3 “一个请求访问不同名称空间的服务”：编排应该在哪一层

热搜词里有一条很具体的场景：“openfeign 一个请求中需要访问不同名称空间的服务”。这在实际项目里非常普遍：一个领域用例需要聚合多个上下文的能力，比如创建订单时既要拿用户资料，又要查库存，还要获取优惠信息。

这个编排逻辑放哪一层，很多人拿不准。放在Controller里太薄，放在FeignClient层会漏掉业务规则，放在领域实体里又会让聚合根背负太多外部依赖。

我的答案是：放在应用服务层的“编排服务”里，同时让领域层定义Gateway接口和必要的数据组装规则。

具体来说，应用服务负责流程编排（先调什么、后调什么、怎么组装），但它不直接dependency injection具体的FeignClient，而是注入领域层定义的各个Gateway接口。跨上下文的业务规则（比如“用户等级为VIP时可用更多的优惠额度”）放在领域服务里，这个领域服务通过Gateway获取数据，而不是通过FeignClient。

// application/service/CreateOrderAppService.java @Service @RequiredArgsConstructor public class CreateOrderAppService { private final UserGateway userGateway; private final InventoryGateway inventoryGateway; private final OrderDomainService orderDomainService; public CreateOrderResult createOrder(CreateOrderCommand cmd) { UserProfile user = userGateway.getProfile(cmd.getUserId()); InventoryState stock = inventoryGateway.checkStock(cmd.getSkuId()); OrderId orderId = orderDomainService.createOrder(user, stock, cmd.getItems()); return new CreateOrderResult(orderId); } }

为什么编排放应用服务而不是领域服务？因为“调用哪些外部上下文、按什么顺序调用”本身不属于任何单一聚合的业务规则，它是用例级别的协调逻辑。放应用层可以把应用流程和领域规则分开：应用层管“过程的顺序”，领域层管“业务的对错”。

但要注意一个度：如果编排逻辑里有大量复杂的业务判断，只是把所有判断都堆在应用服务里，会造成应用服务肥死。这时候要把可复用的判断下沉成领域服务，应用服务只保留流程控制。

2.4 接口粒度要服从聚合完整性，而不是FeignClient数量的便利性

事件风暴还帮你纠正了一个很微妙的倾向——FeignClient的接口设计到底该多大。

很多团队设计远程接口时，习惯按提供方的“资源”来切：用户服务提供一个getUser接口，库存服务提供一个getStock接口，即使一次业务操作只需要其中两个字段，也会把整个对象拉回来。这在DDD里叫“撕裂聚合”或“破坏封装”，因为外部服务拿到了不属于这个用例的数据，同时本地的领域约束也没有地方强制执行。

正确做法是：每个Gateway接口的方法都应该对应一个“领域意图”，而不是一个“HTTP端点”。比如你的用户网关可以拆成getProfile（查用户档案）、verifyIdentity（验证身份状态）、listAddresses（获取收货地址）。每个方法名来自领域通用语言，方法返回值是领域需要的对象，参数是领域对象而不是字符串ID。

这样设计还有个额外好处：当提供方服务的内部结构变化时，只要Gateway接口不变，领域层完全不受影响。防腐层的价值就在这里，它把下游服务的变化围堵在infrastructure层，让核心业务逻辑保持稳定。

3. 跨名称空间服务的OpenFeign契约设计：从接口归属到DTO翻译

3.1 “不同名称空间”在DDD中的含义：限界上下文的物理投射

前面提到热搜词“openfeign 一个请求中需要访问不同名称空间的服务”，如果把它从Kubernetes术语转译成DDD术语，其实就是：一个应用服务在编排时需要访问多个限界上下文提供的服务能力。这里的“名称空间”既是物理部署上的隔离（K8s namespace），也是逻辑边界上的隔离（限界上下文）。

在物理层面，不同名称空间的服务意味着网络地址不同、可能TLS证书不同、访问策略不同。OpenFeign层面能做的处理很直接：给不同名称空间的FeignClient设置不同的name和url，或者在配置文件中为每个上下文单独配置服务发现。

在逻辑层面，不同限界上下文之间要特别注意数据模型的差异性。用户服务里的“用户”和订单服务里的“用户”虽然指同一个现实实体，但它们在不同上下文里关心不同的属性和行为。用户上下文里的User可能包含几十个字段，而订单上下文里的UserProfile只需要userId、姓名和状态。这个差异必须在防腐层处理掉，绝对不能为了省事直接把用户服务的DTO当订单上下文的数据模型用。

3.2 接口定义放消费方还是提供方：一个需要明确回答的问题

Spring Cloud OpenFeign的典型用法是：消费方定义@FeignClient接口，然后在需要的地方注入使用。这个模式下，接口定义天然属于消费方。但从契约管理的角度，业界还有另一种做法：把接口定义在提供方（比如独立的API模块），消费方通过依赖引入。两种方式各有拥趸，但在DDD语境下，我更倾向消费方定义接口，原因有三个：

第一，消费方只定义自己关心的那部分契约，不受提供方全量模型的绑架。比如提供方用户服务有20个字段，订单上下文只需要3个，消费方自己的DTO只需要这3个。如果依赖提供方API模块，很容易被“顺便”把不需要的字段也带进上下文。

第二，消费方定义接口可以让服务演进的耦合更松。提供方服务重构接口时，影响面不会自动扩散到所有消费方，只有真正用到该接口的消费方才需要适配。

第三，DDD的防腐层设计强调“以本地语言为准”。消费方定义的Feign接口名、方法名、字段名完全可以用本上下文的通用语言命名，背后通过配置或映射去适配提供方的实际端点，语义上更干净。

如果你的团队有独立的契约管理需求，比如多个外部系统也要对接这个服务，可以考虑用OpenAPI规范单独维护一份契约文档，让Feign接口和外部客户端都从这份契约生成。但这个方案在不同限界上下文之间的“语义偏差”面前，依然需要防腐层做翻译，所以别指望靠这一招省掉Gateway。

3.3 模型翻译的实操细节：DTO到领域模型的映射

防腐层里最脏最累的活就是DTO转领域模型，这里面坑特别多。

首先是字段不一致。远程接口返回的字段名往往和本地领域模型不一样，比如远程叫customerName，本地叫buyerName。这个好办，用MapStruct注解映射即可：

@Mapper(componentModel = "spring") public interface UserDtoMapper { @Mapping(source = "userName", target = "nickname") @Mapping(source = "status", target = "state") UserProfile toDomain(UserDTO dto); }

但字段名不一致只是表层问题，更麻烦的是类型不一致和结构不一致。远程返回的是一个字符串status："ACTIVE"，而本地需要的是一个枚举UserStatus.ACTIVE；远程返回的是一个扁平Map，本地需要的是一组经过校验的值对象。这时候就不能只靠MapStruct自动映射了，需要手写转换逻辑，在转换过程中完成校验、默认值填充、历史数据兼容。

还有一个经常踩的坑：LocalDateTime和Date的序列化。Feign底层序列化由HTTP消息转换器完成，默认的Jackson对Java时间类型的处理在不同版本里行为不一致。我的建议是：在FeignClient的配置里明确全局时间格式和时区策略，然后所有服务之间约定使用标准ISO-8601字符串或者long类型时间戳作为接口传输格式。这样既避免序列化争吵，也让接口数据在日志和排查时可读。

关键在于：DTO和领域模型是两个世界的东西，它们之间的转换规则本身就是一份值得维护的“契约文档”，不要把它们藏在某个工具类里而没有任何测试保护。至少给核心的转换逻辑写几个单元测试，防止提供方接口悄悄变化时你在生产环境才发现。

3.4 跨上下文调用的异常映射：把技术异常翻译成领域语言

领域层永远不应该看到FeignException。这句话我在代码评审里说过不下十次。可现实里最普遍的情况就是：远程调用失败后，业务代码直接catch FeignException，然后统一返回“系统繁忙”。用户不知道是没权限、没找到、还是服务暂时不可用，这种体验非常差。

防腐层的价值在这时候会体现得淋漓尽致。正确的做法是：在infrastructure层的Gateway实现里捕获Feign的各种异常，翻译成本上下文认识的领域异常。

@Override public UserProfile getProfile(UserId userId) { try { UserDTO dto = userFeignClient.getUser(userId.getValue()); return userDtoMapper.toDomain(dto); } catch (FeignException.NotFound e) { throw new UserNotFoundException(userId); } catch (FeignException.ServiceUnavailable | FeignException.GatewayTimeout e) { throw new RemoteServiceUnavailableException("user-service", e); } catch (FeignException.Unauthorized | FeignException.Forbidden e) { throw new UserCredentialInvalidException(userId, e); } }

这样领域层和应用层都只面对有业务含义的异常类型，它们可以决定哪些异常该重试、哪些该转提示、哪些该触发降级。更进一步的，可以在应用层定义一个全局异常处理策略，把领域异常映射为用户可读的响应码和错误信息。

还有降级。Feign对fallback的支持很完善，但用fallback时要小心一个设计陷阱：fallback类不应该直接放在消费方的应用层，它应该作为infrastructure层里Gateway实现的一部分。因为降级逻辑往往需要返回一个“舒适的数据替代品”，而这个替代品的具体生成方式可能依赖本地缓存、历史数据或其他基础设施，属于典型的技术实现细节。

4. OpenFeign对HTTP/2的真实支持度：底层Client决定上限，DDD决定是否需要

4.1 结论先行：OpenFeign默认不支持HTTP/2

网上搜“openfeign 支持http2么”的人非常多，但很多回答都模糊不清。我先给一个明确结论：OpenFeign本身是一个声明式HTTP客户端框架，它不负责真正的网络IO，网络协议由底层Client执行器决定。所以要回答OpenFeign支不支持HTTP/2，必须先回答它用的底层Client是谁。

Spring Cloud OpenFeign在默认情况下，如果没有额外引入依赖，使用的不是很多人以为的Apache HttpClient，而是JDK自带的HttpURLConnection。这个Client不支持HTTP/2，你配置什么都没用，因为协议栈根本不支持。

如果你的项目里引入了Apache HttpClient或者OkHttp作为Feign的底层Client，那情况就不同了：Apache HttpClient 5.x支持HTTP/2，OkHttp从3.x开始就支持HTTP/2。但引入依赖并启用后，还需要确认连接管理器没有对HTTP/2做限制，以及远程服务端真的协商上了h2协议。

4.2 支持矩阵与验证方法

下面这张表是我根据实践经验整理的，可以直接作为参考：

验证是否真的用了HTTP/2，最直接的方式是看日志。把feign的日志级别调到FULL，请求头里会出现HTTP/2的标记（在HTTP/1.1下则是HTTP/1.1 200 OK）。另一个方式是在服务端开启访问日志，观察协议版本。

但这里有个容易误诊的地方：你在本地用curl或者Postman测试服务端发现HTTP/2可用，不代表你的微服务间通过Feign调用就自动使用了HTTP/2。因为你的微服务两端之间可能经过网关、负载均衡、Service Mesh，这些中间组件对HTTP/2的支持参差不齐，任何一个环节不支持，整个链路都会退化到HTTP/1.1。

4.3 生产环境启用HTTP/2的现实前提

即使你把底层Client换成了支持HTTP/2的版本，生产环境真正跑起来HTTP/2还有一堆条件。首先是服务端必须开启HTTP/2支持。以Spring Boot为例，使用内置Tomcat时，HTTP/2普遍要求开启TLS（h2c理论上可行，但很多网络组件和负载均衡器对明文HTTP/2支持很差，实际线上很少用）。Tomcat的HTTP/2配置还包括并发流的限制、初始窗口大小等调优项。

其次，如果你的服务前面有Nginx、云负载均衡等网关，必须让它们的监听端口也开启HTTP/2并支持向后的h2c或h2代理。很多时候，团队花费了大量精力在应用层配置好HTTP/2，结果链路中间某层没有开启，最后应用日志显示还是HTTP/1.1，排查起来特别费劲。

还有一个被忽视的现实困难：HTTP/2的多路复用特性在Java的HttpClient和Tomcat引入ALPN协商时，会遇到一些老版本依赖库不支持ALPN的问题。比如JDK 8u251之前的版本对ALPN的支持不完善，需要引入Jetty ALPN的boot jar。现在绝大多数团队已经用JDK 11甚至17了，这个问题不那么普遍，但在排查时依然值得留意。

4.4 性能与建模视角：别把HTTP/2当银弹

从DDD的角度看，我对“把Feign升级到HTTP/2”这个诉求一贯保持谨慎。HTTP/2确实能带来多路复用、头部压缩、二进制帧等好处，但这些好处的发挥高度依赖调用场景：如果你服务间的调用是高并发、小而频繁的请求，HTTP/2的多路复用能减少TCP连接数和队头阻塞；但如果你绝大多数调用是低频、大批量的数据传输，那HTTP/2带来的收益很有限。

真正需要OpenFeign走HTTP/2的场景，我更建议直接评估替换方案，比如gRPC。gRPC基于HTTP/2设计，天然支持多路复用、流式调用、强类型契约、负载均衡感知，而且对领域建模里的“接口即契约”有非常好的支持。如果你的主要诉求是跨服务接口的严格契约和高效传输，使用gRPC替换OpenFeign是顺理成章的架构演进，而不是在Feign的底层Client上做各种补丁。

换个角度讲，协议升级解决不了建模问题。如果请求链路里存在大量不合理的远程调用，比如把一个聚合拆到多个服务里然后靠Feign把它们“拼”起来，那么不管是HTTP/1.1还是HTTP/2都救不了你，因为问题出在限界上下文的划分上，而不是传输协议上。实践里，我做过几次HTTP/2性能对比测试，结论很一致：当接口设计合理、数据量适中时，HTTP/1.1开启连接池后和HTTP/2的差距远没有理论数据看起来那么大；而当接口设计混乱时，HTTP/2只是让系统错误地以更高的效率执行错误的事情。

所以我的建议是：先做DDD层面的审视，再谈协议升级。如果你连OpenFeign都还没有归位到infrastructure层，优先解决的问题是防腐层建设，而不是HTTP/2。

5. 从FeignClient满天飞到防腐层收敛：改造步骤、踩坑清单与验收标准

5.1 一套可落地的改造路径

如果你接手了一个FeignClient满天飞的代码库，想往DDD方向收敛，不要想着一天推翻重来。我推荐按下面的步骤推进，每一步都是可验证、可回滚的。

第一步：盘点现状。用脚本或IDE全局搜索@FeignClient注解，把项目里所有远程调用客户端列成清单。对每个FeignClient，标注“被哪些应用服务使用”“返回什么类型”“有没有被领域层直接引用”。

第二步：按限界上下文归类。对照事件风暴产出的上下文地图，把FeignClient划分到对应的外部上下文适配器目录里。如果有的服务边界不清晰，先把它们标记出来，这本身就是一次很好的架构体检。

第三步：在domain层补Gateway接口和领域模型。这一步不要图快，每个Gateway接口的方法、方法名、返回类型都要经过推敲，确保他们使用的是领域语言而不是技术语言。比如getUser是技术语言，getProfile是领域语言。

第四步：在infrastructure层实现Gateway。创建配套的DTO、Mapper和FeignClient，把旧有的调用逻辑搬进来。这一步的核心工作是做模型转换和异常翻译。

第五步：修改application层调用。把直接注入FeignClient的地方替换为注入Gateway接口。每改一个地方，跑一遍对应测试，看领域逻辑是否被改变。

第六步：清理。删除不再被引用的FeignClient、DTO和工具类，更新相关的单元测试和契约测试。

这套路径的关键在于，每一步都以“领域层零技术依赖”为验收目标，同时每一步的改动都可以独立提交、独立发布，不会出现“改到一半系统跑不起来”的状态。

5.2 改造过程中最常见的坑

这个改造路径我走过很多次，也带过不少团队走，几乎每次都会在几个固定的地方踩坑。

第一个坑是循环依赖。Gateway实现依赖FeignClient，FeignClient的fallback又依赖Gateway的场景并不少见。尤其是在引入fallback或降级策略时，如果fallback里注入了包含业务逻辑的领域服务，很容器形成循环依赖链。Spring Boot 2.6之后默认禁止循环依赖，你会直接看到启动报错。解决办法是拆分降级逻辑，让fallback只负责返回兜底数据，不参与领域业务。

第二个坑是序列化不一致。两个服务之间明明用同一个对象名，但字段类型或结构已经悄悄变成不同的版本，运行时直接反序列化报错。拷日志发现是UnknownPropertyException或者Date格式异常。我的经验是：所有跨服务的DTO字段都加上显式约束，字段少可以用基本类型，字段多必须定义清楚类型和格式，还必须有兼容性测试。

第三个坑是上下文丢失，包括Token传递、TraceId传递。FeignClient默认不会把上游请求的Header自动透传给下游，改造后Gateway实现里如果不手动关心上下文，会导致“登录状态过了第一跳就丢”的问题。通常需要实现一个RequestInterceptor，把安全上下文和链路追踪信息塞进Feign请求头。

第四个坑是事务边界。很多团队在应用服务方法上习惯加@Transactional，改造后发现Feign远程调用也在这个事务里。跨服务的网络调用和本地数据库事务混在一起，会让事务时间变得非常长，甚至产生分布式事务的误会。正确做法是把事务边界严格限制在本地数据库操作范围内，远程调用要放在事务之外或者事务只保护本地写操作。

第五个坑是超时配置失效。Feign的connectTimeout和readTimeout默认值很小，在高延迟业务场景下会经常超时。改造时很多人只配置了Feign全局超时，忘了某些接口需要单独的更长的readTimeout。如果超时值设置不对，你会把正常的慢调用误判为远端故障。

5.3 验收清单：怎么判断你的OpenFeign用法DDD合格了

改造完成后，用什么标准来衡量“DDD合格了”？我给自己和团队定过一份很具体的验收清单，分享出来可以直接用：

• domain层代码里没有import任何feign包、okhttp包、apache.http包。
• 所有远程调用接口都通过domain层定义的Gateway接口访问，没有任何业务代码直接引用FeignClient。
• 领域模型里没有远程服务的DTO对象，DTO与领域对象的转换逻辑全部在infrastructure层。
• 远程异常已经翻译成领域异常，领域层看不到FeignException。
• FeignClient的命名、Gateway接口的命名都来自限界上下文内的通用语言，而不是HTTP资源名。
• 不同限界上下文的FeignClient在物理位置上有清晰隔离，不堆在一个大杂烩包里。
• 远程调用的编排逻辑在应用服务层，跨上下文的业务校验在领域服务层。
• 已经用Mock或契约测试覆盖核心Gateway接口的转换和异常映射逻辑。

满足这八条之后，代码库里OpenFeign的用法和DDD之间的关系基本健康了。此时你再回去看当初那个“用户状态校验写在应用服务里”的例子，会发现领域层的领域服务已经承载了校验逻辑，应用服务只负责协调，infrastructure层安静地把远程调用挡在领域之外，一切回到正轨。

如果你准备在团队里推进这件事，我的建议是把门槛放低一点：不需要一次清理完所有FeignClient，可以从改动最频繁的订单或支付链路入手，先让一两个限界上下文达到这个验收标准，跑出样例后再推广。DDD不是一个周末能突击完的项目，而是一个持续打磨边界的过程。每次代码评审时多问一句“这个Feign调用为什么会出现在这一层”，时间久了，团队的架构直觉自然就出来了。