Spring Boot微服务：实体与DTO含业务方法是否违反关注点分离？

现有代码实现 #

Order 实体类 #

@Entity
class Order {

    @Id
    private Long id;

    @OneToMany
    private List<Product> products;
    
    // getters setters

    public Product getMainProduct() {
        final String someBusinessValue = "A";

        return products.stream()
                .filter(product -> someBusinessValue.equals(product.getSomeBusinessValue()))
                .findFirst()
                .orElseThrow(() -> new IllegalStateException("No product found with someBusinessValue 'A'"));
    }
}

OrderRequest 入参DTO类 #

class OrderRequest {
    
    private List<ProductDto> productDtos;
    
    // getters setters

    public ProductDto getMainProductDto() {
        final String someBusinessValue = "A";

        return productDtos.stream()
                .filter(productDto -> someBusinessValue.equals(productDto.getSomeBusinessValue()))
                .findFirst()
                .orElseThrow(() -> new IllegalStateException("No productDto found with someBusinessValue 'A'"));
    }
}

设计争议与现有方案问题 #

上述代码中，Order实体和OrderRequestDTO都包含了从商品列表中获取「主商品」的业务方法，该方法仅在服务层的多处逻辑中使用。但收到设计意见认为：

• 此举会使DTO与DB实体跨层紧耦合，违反关注点分离原则
• 服务层不应知晓控制器的请求参数，控制器也不应耦合服务层返回内容

建议新增中间DTO OrderDto：

class OrderDto {
    
    private List<ProductDto> productDtos;

    private ProductDto mainProductDto;
    
    // getters setters
}  

由控制器将OrderRequest转换为OrderDto后传入服务层，服务层则将OrderEntity转换为OrderDto再处理，同时将获取主商品的逻辑移至映射器中。但该方案存在明显问题：

• 增加服务层内的大量转换操作
• 更新实体时需处理两个中间DTO的状态同步
• 需花费大量时间重构整个微服务

现提出疑问：

1. 在实体与入参DTO中保留这类业务方法是否属于不良设计？
2. 有无其他更优的重构方案？

回答 #

一、实体与入参DTO中保留业务方法是否为不良设计？ #

不能一概而论，需分场景判断：

• 实体类中的getMainProduct()：这属于领域逻辑，放在实体类中符合DDD（领域驱动设计）思想——实体应封装自身的业务行为和规则，而非单纯作为数据载体。只要该逻辑和订单自身业务属性强相关，放在实体里完全合理，不属于不良设计。
• OrderRequest中的getMainProductDto()：此处确实存在问题。OrderRequest是接收前端请求的DTO，职责应聚焦数据传输与参数校验，不应承载业务逻辑。而且该方法和实体类中的逻辑完全重复，造成代码冗余，同时让服务层依赖请求DTO，违反关注点分离原则——服务层应聚焦业务逻辑，而非绑定控制器层的请求对象。

二、更优的重构方案 #

方案1：抽离通用业务逻辑到工具类

把获取主商品的逻辑抽成独立工具类，避免代码重复：

public class OrderBusinessUtils {
    private static final String MAIN_PRODUCT_VALUE = "A";

    public static Product getMainProduct(List<Product> products) {
        return products.stream()
                .filter(product -> MAIN_PRODUCT_VALUE.equals(product.getSomeBusinessValue()))
                .findFirst()
                .orElseThrow(() -> new IllegalStateException("No product found with someBusinessValue 'A'"));
    }

    public static ProductDto getMainProductDto(List<ProductDto> productDtos) {
        return productDtos.stream()
                .filter(productDto -> MAIN_PRODUCT_VALUE.equals(productDto.getSomeBusinessValue()))
                .findFirst()
                .orElseThrow(() -> new IllegalStateException("No productDto found with someBusinessValue 'A'"));
    }
}

• 调整实体和DTO：
  • Order实体的getMainProduct()改为调用工具类方法：

    public Product getMainProduct() {
        return OrderBusinessUtils.getMainProduct(this.products);
    }
    

  • 删除OrderRequest中的getMainProductDto()方法，服务层需要获取主商品时，直接调用工具类对应方法处理OrderRequest中的productDtos。

方案2：引入领域服务处理业务逻辑

如果获取主商品的逻辑后续可能扩展（比如规则可配置、与其他领域对象交互），可将其放到领域服务中：

@Service
public class OrderDomainService {
    private static final String MAIN_PRODUCT_VALUE = "A";

    public Product getMainProduct(Order order) {
        return order.getProducts().stream()
                .filter(product -> MAIN_PRODUCT_VALUE.equals(product.getSomeBusinessValue()))
                .findFirst()
                .orElseThrow(() -> new IllegalStateException("No product found with someBusinessValue 'A'"));
    }

    public ProductDto getMainProductDto(List<ProductDto> productDtos) {
        return productDtos.stream()
                .filter(productDto -> MAIN_PRODUCT_VALUE.equals(productDto.getSomeBusinessValue()))
                .findFirst()
                .orElseThrow(() -> new IllegalStateException("No productDto found with someBusinessValue 'A'"));
    }
}

• 服务层直接注入该领域服务获取主商品，同时删除OrderRequest中的业务方法；实体类可保留getMainProduct()作为便捷方法，内部调用领域服务，或直接由服务层通过领域服务获取。

方案3：优化中间DTO方案，降低转换成本

如果必须遵循“服务层不依赖请求DTO”的原则，可优化原中间DTO方案：

• 让控制器层负责将OrderRequest转换为OrderDto（仅做数据映射，主商品逻辑在转换时调用工具类/领域服务填充）
• 服务层只与OrderDto和Entity交互，更新时仅处理OrderDto到Entity的转换，无需同步多个DTO状态
• 使用MapStruct等映射工具自动处理DTO转换，减少手动编写转换代码的工作量，降低重构成本

内容的提问来源于stack exchange，提问作者George Lvov