围绕真实项目里常见的 Liquibase（XML）反模式，按问题整理我目前更倾向采用的一些做法：schema 归属、master changelog 组织、changeSet ID 命名、XSD 版本、初始化策略、expand-and-contract、大表 DDL、K8s lock、回滚 / tag、context / labels、Testcontainers 验证与 CI 检查。

微服务规模增大后我开始补的两类结构化文档，问答体：ADR 记下为什么这样选，catalog-info.yaml 记下这是什么、归谁、依赖什么。

API 与 event contract 的兼容性保障按问答拆开：BFF 对外用 oasdiff 守 OpenAPI spec，内部 BFF 到 MS、MS 到 MS 用 JSON Schema 快照补 japicmp 的盲区，Kafka 事件再加 per-event schemaVersion。

只共享 contracts 往往还不够。按我目前的理解，更稳妥的做法是把 ArchUnit、japicmp、Deprecation/Sunset 头、ignore-unknown、WireMock 组合起来，Shop Platform 里的落地方式和几份可参考资料放在一起。

多模块 Maven 单仓微服务平台里，脚手架我选了 Maven Archetype 而不是 Spring Initializr，选型理由、六类 Archetype 的分层逻辑、为什么 Archetype 本身也要有测试、版本怎么维护，都收在这一篇。

Tracing 断链很少是 @HttpExchange 能解决的问题。一次 Spring Boot 3.5 + Micrometer + OpenTelemetry 的复盘：用 W3C Trace Context、baggage 白名单和 auto-configured RestClient.Builder 把 trace 和业务上下文一起稳定地跨服务传下去。

多仓库微服务的文档体系，我最后用的是中央架构 Repo 加各服务 Repo 内的 /docs/ 目录，再用 Docusaurus 收成统一入口，文档贴近代码，检索入口只有一个。

接入真实支付前，得先把支付抽象和 provider 边界理顺。Shop Platform 当前实现里，wallet-service 的 PaymentIntent 抽象、Stripe/PayPal/Klarna/Wallet 支付方式矩阵、Mock 与真实网关的切换已经跑通，webhook、退款幂等和 Payment Element 还没落地。

BFF 与微服务之间到底该共享到哪一步？Shop Platform 的 monorepo 实践之外，共享 contracts、共享 client 和契约测试在 polyrepo 下各有 tradeoff，我目前更倾向其中一种组合。

在 code agent 普及的背景下，我在 Shop Platform 用 ArchUnit 作为可执行的 harness，它在微服务、monorepo 和普通 repo 里的落地方式各不相同。