/tags/cdct/ Recent content in cdct on Hugo -- gohugo.io en Tue, 14 Apr 2026 10:10:00 +0800 /posts/java-contract-scc-poc-recap/ Tue, 14 Apr 2026 10:10:00 +0800 /posts/java-contract-scc-poc-recap/ 这篇文章可以看作 《Contract First 工作流：让 AI 帮你写 OpenAPI YAML》 的实现篇。上一篇讨论的是“spec 如何成为协作中心”；本文只讨论当接口边界已经确定之后，JVM 团队如何把contract变成验证、stubs 和 CI Quality Gates。 微服务接口兼容性的问题，通常不是在设计阶段暴露，而是在某个 PR 合并之后才通过联调、回归测试，甚至线上流量被发现。这个 java-contract 仓库的目的，就是把这类问题尽量前移到提交阶段，用 contract testing 把 producer 和 consumer 之间的接口约束固定下来。 这篇文章不打算再展开 AI 生成 OpenAPI、style guide 或 breaking change 治理这些协作层话题。它更像是一次基于当前仓库完成态的工程复盘：为什么这个 Java 25 + Spring Boot 3.5 + Maven 多模块项目最终选择了 Spring Cloud Contract，contract如何在仓库里流动，以及这套做法如何进入 CI，成为一条可执行的兼容性 Quality Gates。 项目代码：github.com/meirongdev/java-contract 有了 OpenAPI 和集成测试，还需要 SCC 吗？ 采用 Contract First 工作流的团队常会遇到这个问题。我的理解是：三者关注的粒度不同，不互相替代。 OpenAPI spec 描述的是接口形状：字段、类型、必填约束、状态码有哪些。集成测试验证的是系统整体行为：多个服务部署在一起能否跑通。SCC 填的是中间那层——接口行为：在某个具体场景下，一次请求会得到什么确定性响应，且这个断言在提交阶段就能被执行。 以 /users/{id} 为例。OpenAPI 会告诉你：