在多服务 spring web 应用中，不同服务因 rest 交互而各自维护相同结构的 pojo，易引发同步维护难题；本文阐述为何共享数据模块并非最优解，并推荐基于接口契约、版本化和上下文隔离的可持续演进方案。
当多个 Spring Boot（或传统 Spring）服务通过 REST 相互调用时，常见现象是：/users 服务定义 UserData，/emails 服务为解析其响应又定义了结构完全一致的 UserData。表面看这是代码重复，但强行“去重”——例如抽取为独立 shared-data-objects 模块并让各服务依赖它——实则埋下严重架构隐患。
❌ 共享 POJO 模块的危害远超重复代码
com.myapp shared-data-objects 1.2.0
- 破坏服务自治性：一旦 shared-data-objects 发布新版本（如新增 @NotNull 校验或重命名 firstName → givenName），所有依赖它的服务必须同步编译、测试、发布——哪怕只有 /users 服务实际需要该变更。
- 模糊边界契约：REST 的本质是松耦合的 HTTP+JSON 协议交互，而共享类库将序列化细节（如 Jackson 注解、Lombok 行为、字段顺序）硬编码进二进制依赖，使服务间契约从“语义契约”退化为“实现契约”。
- 阻碍独立演进：未来 /emails 服务可能只需 User.id 和 User.email，而 /billing 服务需完整用户档案。若共用 POJO，则任一服务的精简或扩展需求都会波及他人。
✅ 正确实践：以 Bounded Context 为指导，拥抱“合理重复”
Martin Fowler 提出的 Bounded Context（限界上下文） 是解题关键：每个服务代表一个独立业务域，其数据模型应由该域的语义驱动，而非技术便利性驱动。
1. 各服务自主定义 DTO，严格遵循接口契约
- /users 服务在 OpenAPI（Swagger）中明确定义 GET /users/{id} 的响应 Schema：
components: schemas: UserData: type: object properties: id: { type: integer } fullName: { type: string } email: { type: string } - /emails 服务不引用任何外部类，而是基于此契约生成自己的 EmailServiceUserDto：
public class EmailServiceUserDto { private Long id; private String fullName; // 注意：此处字段名与 users 服务保持一致，但属于本服务的独立定义 private String email; // 构造函数、Jackson 注解、校验逻辑均由本服务控制 }
2. 使用契约优先工具自动化同步（非代码共享）
借助 OpenAPI Generator，在 CI 流程中自动生成各服务所需的客户端 DTO：
# 在 emails 服务构建阶段执行（无需人工维护） openapi-generator generate \ -i https://users-service/api-docs.json \ -g java \ --model-name-suffix Dto \ -o src/main/java/com/myapp/emails/dto/generated/
→ 生成的是 EmailsUserDto，而非 SharedUserDto，所有权仍归属 /emails 服务。
3. 为变更建立显式版本化策略
当 /users 服务需新增字段 timezone：
- v1 接口保留：GET /users/{id} 维持原 JSON 结构（向后兼容）
- 发布 v2 接口：GET /users/v2/{id} 返回含 timezone 的新 Schema
- /emails 服务按需在后续迭代中升级到 v2，并生成新的 EmailsUserV2Dto —— 无强制升级，无跨服务阻塞。
总结：重复是表象，契约才是核心
不要为消除“看起来一样”的 POJO 而牺牲服务独立性。真正的 DRY（Don’t Repeat Yourself）原则在此场景下应解读为：Don’t Repeat Your Contracts —— 通过统一的 OpenAPI 规范、自动化代码生成和语义化版本控制，确保各服务对同一业务概念的理解一致，而非让它们共享同一段 Java 字节码。让每个服务成为自己数据模型的权威，才是微服务架构可持续演进的基石。
