/tags/monorepo/ Recent content in monorepo 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. /posts/archunit-harness-microservices-monorepo/ Tue, 21 Apr 2026 12:54:15 +0800 /posts/archunit-harness-microservices-monorepo/ 📦 本文基于的完整项目源码：meirongdev/shop 背景：在 code agent 时代重新谈 ArchUnit 这两年很多团队都在引入 code agent。它们写代码的速度很快，能补样板、改依赖、重构包结构、批量修复低级问题，但也因此更容易把"本来只存在于文档和 review 习惯里的约束"绕过去。 下面这些问题，人在赶时间时会犯，agent 在缺少硬约束时也会犯： 为了省事直接加 @Autowired 字段注入 在 BFF 里偷偷落一个 @Entity Controller 直接访问 Repository Kafka consumer 没有幂等保护 契约模块慢慢混入 Spring Web / JPA 依赖 这些都不是"功能对不对"的问题，而是"代码还在不在团队允许的边界里"的问题。在我看来，ArchUnit 的价值就在这里：它把架构约束从口头约定变成可执行测试。 这个视角并不是孤立的观察。Birgitta Böckeler 在 2026 年 2 月的 Harness Engineering, First Thoughts 里把这种"给 agent 搭结构化反馈 harness"的工程学命名了出来，并明确问到：“Have you experimented with structural testing frameworks like ArchUnit?” 同一时期，Sasha Podlesniuk 在 2026 年 1 月的 From Prompts to Invariants: Re-architecting Systems with ArchUnit and LLMs 里具体写了怎么把 ArchUnit 的失败信息当作 agent 的反馈信号。更早的概念根源是 Neal Ford 在《Building Evolutionary Architectures》里提出的 fitness function——结构化测试就是最典型的、可执行的 fitness function。