/tags/polyrepo/ Recent content in polyrepo on Hugo -- gohugo.io en Wed, 22 Apr 2026 00:30:00 +0800 /posts/microservices-contract-sharing-polyrepo-tradeoffs/ Wed, 22 Apr 2026 00:30:00 +0800 /posts/microservices-contract-sharing-polyrepo-tradeoffs/ 📦 本文基于的完整项目源码：meirongdev/shop 先给结论 如果你只想先看我的当前结论，再决定要不要继续往下看，可以先看这一版： 我更倾向于共享 contracts，而不是共享 client 接口。 即使在 monorepo 里，我也会尽早把 shared client 下沉到各 caller 自己的 client/ 包。 如果未来要拆成 polyrepo，我目前更偏向“共享 contracts artifact + caller 自己写 client + 契约测试兜底”。 只有当你真的面临多语言 SDK、外部开放接口，或者已经有成熟的平台治理能力时，我才会认真考虑 spec-first + 代码生成。 换句话说，这篇文章真正要回答的不是“Client 接口写在哪”，而是：跨服务的边界，到底该共享“数据契约”，还是连“调用方式”也一起共享。 起点：一个具体的问题 先用一个具体例子，把问题落到地上。 在早期的 shop 项目里，BFF 调下游 domain service 的链路是这样的： shared/shop-contracts/shop-contracts-*：按 domain 拆分的契约模块，只有路径常量（OrderApi.CART_LIST）和 DTO（record），不依赖 Spring，也不含任何业务逻辑。 shared/shop-clients：集中放所有 @HttpExchange 接口（OrderServiceClient、MarketplaceServiceClient …），被 buyer-bff、seller-bff 一起依赖。 shared/shop-common/shop-starter-http-client：统一的 ShopHttpExchangeSupport，负责用 RestClient 构造代理、挂拦截器、传 trusted headers、做错误映射。 BFF 侧的写法大致是： @Bean OrderServiceClient orderServiceClient(ShopHttpExchangeSupport support, BuyerClientProperties properties) { return support.