如何在JPA中持久化包含策略对象的复杂实体？

阿华AIGC实验室

2026-5-22

在Spring Boot JPA DDD项目中给领域实体加策略模式的实践

嘿，刚好我在Spring Boot JPA结合DDD的项目里折腾过类似的场景——当领域模型越来越复杂，把一坨复杂逻辑拆成策略模式确实能让实体清爽很多，但直接在@Entity里放StrategyObject肯定会踩坑，我来分享下实际可行的做法和需要注意的点。

先说说核心问题

你想给ComplexEntity加策略模式的思路完全没问题，但直接把策略对象塞进实体里会碰到两个麻烦：

JPA不认这种非实体/非嵌入类的对象，除非你硬要序列化存进去，但那样会带来序列化耦合、没法查策略字段的问题，得不偿失
策略逻辑通常要依赖其他服务或者配置，直接让实体持有这些依赖，会把领域实体搞得不纯洁，违背DDD里实体只聚焦领域逻辑的原则

两种可行的实现方案

方案1：存策略标识，运行时动态拿策略（最推荐）

这是最符合DDD和JPA规范的玩法，核心就是实体只存“用哪个策略”的标识，实际的策略实例交给Spring容器管理，用工厂来动态获取：

// 先整个枚举，标记不同的策略类型
public enum StrategyType {
    ORDER_DISCOUNT, USER_VIP
}

// 策略接口，定义统一的业务方法
public interface ComplexStrategy {
    void execute(ComplexEntity entity, OtherEntity other);
}

// 具体策略实现，做成Spring Bean，方便注入依赖
@Component
public class OrderDiscountStrategy implements ComplexStrategy {
    // 比如这里可以注入Repository或者其他服务
    @Autowired
    private OrderRepository orderRepo;

    @Override
    public void execute(ComplexEntity entity, OtherEntity other) {
        // 这里写具体的折扣逻辑
    }
}

// 领域实体，只存策略标识，不存策略对象
@Entity
public class ComplexEntity {
    @Id
    private String id;
    // 其他简单字段
    private String businessNo;
    // 用枚举存策略类型，JPA直接支持枚举持久化
    @Enumerated(EnumType.STRING)
    private StrategyType strategyType;

    // 业务方法：需要外部传入策略工厂来获取对应的策略
    public void doBusinessLogic(OtherEntity other, ComplexStrategyFactory strategyFactory) {
        ComplexStrategy strategy = strategyFactory.getStrategy(strategyType);
        strategy.execute(this, other);
    }
}

// 策略工厂，用Spring的构造注入自动收集所有策略实现
@Component
public class ComplexStrategyFactory {
    private final Map<StrategyType, ComplexStrategy> strategyMap;

    public ComplexStrategyFactory(List<ComplexStrategy> strategies) {
        this.strategyMap = strategies.stream()
                .collect(Collectors.toMap(this::matchStrategyType, Function.identity()));
    }

    // 这里根据策略类匹配对应的枚举，也可以用注解来标记，更灵活
    private StrategyType matchStrategyType(ComplexStrategy strategy) {
        if (strategy instanceof OrderDiscountStrategy) {
            return StrategyType.ORDER_DISCOUNT;
        } else if (strategy instanceof UserVipStrategy) {
            return StrategyType.USER_VIP;
        }
        throw new IllegalArgumentException("找不到对应的策略类型");
    }

    public ComplexStrategy getStrategy(StrategyType type) {
        return strategyMap.get(type);
    }
}

这种方式的好处是：实体保持干净，策略的依赖由Spring管理，新增策略只需要加个实现类和枚举值，完全符合开闭原则。

方案2：序列化存储策略状态（谨慎用）

如果你的策略不仅有行为，还需要携带专属的状态参数（比如某个策略的阈值、配置项），可以考虑把策略对象序列化成JSON存在实体字段里，但这种方式有不少限制：

策略必须是纯POJO，不能依赖任何Spring Bean，不然序列化会出问题
不能查询策略里的字段，因为存在数据库里是文本
要注意序列化的兼容性，比如策略类改了字段，老数据反序列化可能报错

代码示例参考：

@Entity
public class ComplexEntity {
    @Id
    private String id;
    // 其他字段
    // 用TEXT类型存序列化后的策略对象
    @Column(columnDefinition = "TEXT")
    @Convert(converter = StrategyObjectConverter.class)
    private StrategyObject strategyObject;

    public void doLogic(OtherEntity other) {
        strategyObject.execute(this, other);
    }
}

// 自定义JPA转换器，处理策略对象的序列化和反序列化
public class StrategyObjectConverter implements AttributeConverter<StrategyObject, String> {
    private final ObjectMapper objectMapper = new ObjectMapper();

    @Override
    public String convertToDatabaseColumn(StrategyObject strategy) {
        try {
            return objectMapper.writeValueAsString(strategy);
        } catch (JsonProcessingException e) {
            throw new RuntimeException("序列化策略对象失败", e);
        }
    }

    @Override
    public StrategyObject convertToEntityAttribute(String dbData) {
        try {
            return objectMapper.readValue(dbData, StrategyObject.class);
        } catch (JsonProcessingException e) {
            throw new RuntimeException("反序列化策略对象失败", e);
        }
    }
}

// 策略基类，纯POJO，不带任何依赖
public abstract class StrategyObject {
    public abstract void execute(ComplexEntity entity, OtherEntity other);
}

// 具体策略，带自己的状态参数
public class ThresholdStrategy extends StrategyObject {
    private Integer threshold; // 策略专属的阈值参数

    @Override
    public void execute(ComplexEntity entity, OtherEntity other) {
        // 基于阈值的业务逻辑
    }
}