在多服务场景下：复用请求DTO还是通过复制解耦？

假设Spring Boot应用中有一个简单的REST控制器，接收CalculationDetails请求DTO：

@PostMapping
public CalculationResponse calculateAverage(@RequestBody CalculationDetails details) {
    return calculationService.calculateAverage(details);
}

public record CalculationDetails(@JsonProperty("value_1") BigDecimal bd1,
                                 @JsonProperty("value_2") BigDecimal bd2,
                                 @JsonProperty("sourceList") List<CalculationSource> sources) {}

当前CalculationDetails类被其他不属于同一功能的服务方法和映射器类复用，且目前数据结构完全一致。现在面临两种方案选择：

1. 将CalculationDetails移至common包，让其他服务直接复用
2. 保留当前控制器/服务专用的CalculationDetails，创建一个结构完全相同的副本

方案2实现解耦但会有代码重复，方案1复用代码但会增加耦合，哪种方案更合理？

核心判断依据是：这些复用场景是否属于同一业务上下文，以及未来是否大概率会产生差异化需求。

• 如果复用的场景本质上是同一业务概念的不同使用场景，且未来很长一段时间内数据结构不会有差异化调整（比如都是用来传递“计算基础参数”这一核心业务信息），那优先选方案1（移至common包复用）。
  理由：代码重复带来的维护成本远大于耦合的风险，毕竟同一业务概念的DTO本就该保持一致，硬拆分反而会导致后续同步修改的麻烦。

• 如果复用的场景只是当前数据结构碰巧一致，但分属不同的业务域（比如一个是“平均值计算”，另一个是“数据校验”，两者核心业务逻辑完全无关），那优先选方案2（创建副本）。
  理由：不同业务域的DTO未来极有可能因为各自业务需求的变化而修改结构（比如平均值计算可能要加weight字段，而数据校验可能要加validateRule字段），提前解耦能避免一个业务的修改影响到另一个完全无关的业务，减少意外风险。

如果实在纠结，可以先选方案1，但给CalculationDetails加上清晰的业务注释，明确它代表的核心业务含义；如果后续出现差异化需求，再拆分出不同的DTO即可——这种“先复用再拆分”的成本通常比“先拆分再合并”更低。

内容的提问来源于stack exchange，提问作者Robert Strauch