共享模型与复制模型的耦合取舍

两个服务之间要传数据（比如下单服务需要目录服务返回的图书信息），数据模型该怎么共享有两条路：抽成一个共享库让双方都依赖它，能保证模型永远一致不会跑偏，代价是引入了实现层面的耦合——共享库一变，所有依赖它的服务都要跟着重新构建发布；或者干脆各自维护一份重复的模型定义，服务之间彻底解耦，代价是原始模型变了没人会自动通知你，只能靠消费者驱动契约测试（consumer-driven contract）这类自动化手段在原始服务改了 API 之后尽早发现下游模型已经过期。发散：这本质是服务化架构里”减少显式代码耦合”和”减少隐式模型漂移风险”之间的取舍——共享库把耦合摆在明面上，改起来疼但一改就全体感知；各自复制把耦合藏起来，短期舒服但代价是需要额外一层测试基础设施去弥补本该由编译器保证的一致性。