方法内重复逻辑重构：用领域模型扩展替代if-else

1. 方法内重复逻辑的典型症状与重构价值

1.1 三种最常见的“重复逻辑”形态

在日常Java开发里，“方法内重复逻辑”其实有几种不同的面貌，很多时候我们第一眼没意识到它是重复。我把这些年代码评审里见过的高频形态整理成了三类，你可以对照自己的项目看看有没有中招。

第一种是散弹式if-else。一个订单金额计算的方法里，先判断订单类型，再判断用户等级，再判断是否新用户，再判断是否节假日，层层嵌套。等业务加了第六个条件，你发现要同时改动三四个方法，而且每个方法里都有同样一串“是否为特殊订单”的判断。这类代码最大的问题是复制粘贴成本低，所以越堆越多。

第二种是数列式判断。看起来每个分支都不同，但本质上都是在做同一件事——根据某个业务类型匹配不同的计算规则或处理策略。常见的写法是用switch或if-elseif逐个罗列，然后每加一种类型就要改动主方法，还要小心翼翼不破坏已有分支。

第三种是隐性业务规则散落。同一个业务规则，比如“VIP客户订单金额满200包邮”“生鲜类目不允许使用优惠券”，会出现在订单校验、金额计算、优惠券核销、售后处理等多个方法中。这些规则不在一个地方统一管理，而是在各个方法里用不同的代码逻辑重复表达。这类最隐蔽，因为每处代码写法略有不同，但业务含义完全一致。

如果你在项目里见过其中任何一种形态，那这个项目就已经具备了通过领域模型重构的基础条件。重构的核心思路不是把重复代码删掉，而是把重复背后的业务规则抽到一个统一的领域模型里，让模型来承载行为。

1.2 重复逻辑的根因：贫血模型与过程式思维

可能很多人没有认真想过：为什么要重构方法内重复逻辑？代码复制粘贴一下也能跑，甚至本地测试都过了，问题出在哪？

问题的根子在于贫血模型。这种项目里，实体类就是一堆getter/setter，没有任何业务行为，所有逻辑全部写在Service层的方法里。Service层的方法把数据从数据库捞出来，然后在这个方法里做判断，在那个方法里再判断一遍，规则散落在各个方法中。

举个很简单的例子：订单实体Order里只有订单类型、金额、用户ID这些字段，没有行为。判断“订单是否可以取消”的逻辑写在OrderService.cancel()里，判断“订单是否允许售后”的逻辑写在AfterSaleService.apply()里。两个方法里都有一句类似的代码——判断订单状态是否为“已完成”且距支付时间是否超过7天。这个规则一旦调整，就要同时改两处。漏改一处，业务上就会出现一个订单能取消但不能售后、或者反过来不能取消却能售后的bug。

贫血模型的维护成本，是随着业务规则数量上升呈指数级增长的。而领域模型重构，本质上就是把这些散落在方法里的规则“归位”到实体、枚举、值对象等模型里，让模型自带行为。这就是标题里“领域模型扩展”的实际含义。

1.3 重构的价值：不是代码洁癖，是维护成本

一提到重构，总有人觉得这是技术洁癖，觉得“能跑就行”。但站在项目长期维护的角度，方法内重复逻辑的直接后果是需求变更时改动点多、容易漏改。行业里有个常被引用的数据是，修复缺陷的成本随缺陷引入到发现的时间跨度呈指数级上升。代码结构混乱导致的逻辑不一致，正是引入缺陷的重要来源。

从我实际的维护经验来看，重构重复逻辑带来的收益最直观的体现是三件事：第一，需求变更时只需要改一个模型，不需要在多个方法里手动同步；第二，新同事接手代码时，通过模型能够快速理解业务规则，不需要在Service层里翻几十行if判断；第三，单元测试可以针对模型直接写，覆盖面更全，执行速度更快，不像集成测试那样需要启动整个Spring容器。

尤其是第三点，很多团队忽略。把逻辑收拢到领域模型之后，测试面会显著缩小。比如订单金额计算，如果规则在模型的枚举或策略里，那可以直接new一个枚举实例、传入上下文就能单测；而如果规则全在Service方法里，就得Mock一堆仓库和数据，测试成本高到让人不想写测试。

2. 领域模型扩展的核心设计思路

2.1 把“判断”变为“行为”：多态替代条件分支

领域模型扩展的第一个核心思路，是把“判断”变成“行为”。很多人第一眼不理解这句话的意思，我用一个最通俗的例子说明。

假设你有一个订单计算运费的方法，现在有普通订单和VIP订单两种类型。普通的写法是：

java复制public BigDecimal calculateFreight(Order order) {
    if ("VIP".equals(order.getUserLevel())) {
        if (order.getAmount().compareTo(new BigDecimal("200")) >= 0) {
            return BigDecimal.ZERO;
        }
        return new BigDecimal("10");
    }
    return new BigDecimal("20");
}

这段代码用if-else区分用户等级，每增加一个用户等级或一种运费规则，都要往这个方法里怼代码。通常改个三五次之后，这个方法就变成了一个巨无霸。

如果引入领域模型，思路就变成了：让“用户等级”这个模型自己有运费计算的能力。也就是让数据模型带上行为：

java复制public interface FreightPolicy {
    BigDecimal calculate(Order order);
}

然后让VIP用户等级和普通用户等级分别实现这个接口。这种做法背后依赖的是面向对象的多态特性——调用方通过模型的抽象类型触发匹配的行为，不关心具体是哪个等级，更不需要写if判断。

类似思想在很多经典代码里都有体现。比如Spring的Environment抽象、JDK的Comparator、MyBatis的类型处理器，本质上都是在做“用多态替代条件分支”这件事。

2.2 模型分级的三个层次：枚举行为、策略模式、状态机

在真正动手之前，有一个重要认知需要建立：领域模型扩展的落地方式，不是一个方案打天下，而是根据逻辑复杂度分级使用。

第一级是枚举行为扩展。适合重复逻辑的分支条件是固定不变的类型码。比如订单状态、支付渠道、用户等级，这些枚举值基本稳定，不会频繁新增。做法是把计算方法放到枚举里，让枚举自己承载计算行为。这个方案最轻量，适合快速见效。

第二级是策略模式扩展。适合分支条件相对固定、但每种类型的算法比较复杂且可能独立演进的场景。不同的策略实现类可以单独维护、单独测试，甚至动态注册。这个方案比枚举方案灵活，但会多一些类文件。

第三级是状态机。适合状态流转复杂、一个状态下有多种允许动作、动作还会改变状态的场景。比如订单的“待支付”“已支付”“已发货”“已完成”“已取消”之间有一整套合法迁移规则，用状态机来描述比在Service里反复if-else判断要清晰很多倍。

我见过很多人一上来就套状态机或策略模式，结果逻辑明明只是一个简单的类型判断，硬生生造出来十几个类，维护成本反而更高。所以分级设计的意义在于：用最匹配的复杂度去解决问题，而不是用最高的复杂度展示技术。

2.3 选型评估：什么时候值得动手重构

在实际项目里，有个问题比“怎么做”更早出现——“该不该做”。我总结了一些判断依据，满足其中两条以上，就值得用领域模型重构。

第一个判断依据是同一段规则出现了三处及以上的复制。一处两处可能是巧合，三处以上就是规则需要被模型化的信号。三这个数字是很多重构书籍里提到的最小重复次数，我也在实践中验证过，一到两次重构收益不明显，三次以上收益就开始显著了。

第二个判断依据是新增一种业务类型时需要修改两个以上的方法。每加一个订单类型，要跑去价位计算、库存扣减、优惠券核销等好几个方法里补判断，这在项目演进过程中几乎是必然发生的。如果已经出现过一次这种情况，就应该考虑重构了。

第三个判断依据是当前的if逻辑已经让人难以在一屏之内读完。出现这个信号时，即使重复次数没达到三，也可以先拆出模型，因为方法已经过长了。人的工作记忆有限，一屏之内如果读完不了一个方法的逻辑，就很容易在改动时犯低级错误。

第四个依据是你发现自己在“复制代码然后改几个条件”。这是最危险的信号，因为这意味着规则已经失控，你在用复制粘贴的方式进行变更管理，而这种做法从长期看一定会在某个需求变更时漏改一处。

3. 实操案例：订单优惠计算的完整重构过程

3.1 原始代码：一个典型的if-else堆积方法

为了让你看得更直观，我用一个相对完整的案例来展示整个重构过程。假设我们有一个电商订单系统，订单金额计算是业务中最核心也最容易被改烂的地方。以下是现有逻辑，已经经历了四次需求迭代：

• 需求一：普通订单按原价计算。
• 需求二：VIP用户享受95折。
• 需求三：生鲜类目不参与任何折扣。
• 需求四：新用户首单额外减10元。

对应的原始代码如下：

java复制public class OrderService {
    public BigDecimal calculatePayAmount(Order order, User user, boolean isFirstOrder) {
        BigDecimal amount = order.getProductAmount();
        
        // 需求四：新用户首单额外减10元
        if (isFirstOrder) {
            amount = amount.subtract(new BigDecimal("10"));
        }
        
        // 需求三：生鲜类目不参与任何折扣
        if ("FRESH".equals(order.getCategory())) {
            return amount;
        }
        
        // 需求二：VIP用户享受95折
        if ("VIP".equals(user.getLevel())) {
            amount = amount.multiply(new BigDecimal("0.95"));
        }
        
        return amount;
    }
    
    public BigDecimal deductCoupon(Order order, User user, Coupon coupon, boolean isFirstOrder) {
        if ("FRESH".equals(order.getCategory())) {
            return BigDecimal.ZERO;
        }
        if ("VIP".equals(user.getLevel()) && isFirstOrder) {
            // VIP首单还可叠加优惠券
            return coupon.getAmount();
        }
        // 普通用户首单不叠加优惠券
        if (isFirstOrder) {
            return BigDecimal.ZERO;
        }
        return coupon.getAmount();
    }
}

这段代码的问题很明显："FRESH".equals(order.getCategory())这个判断在calculatePayAmount和deductCoupon里出现了两次，"VIP".equals(user.getLevel())出现了三次。每次用户等级增加或者类目增加，都要这里改一下、那里改一下，漏改的情况我已经见过太多次了。

3.2 第一轮重构：用枚举承载行为，消灭散落的类型判断

第一轮重构的目标不是大动干戈，而是把零散的业务规则聚拢到模型里。

首先引入一个用户等级的枚举，让它自己具备折扣计算能力：

java复制public enum UserLevel {
    NORMAL {
        @Override
        public BigDecimal applyDiscount(BigDecimal amount, OrderInfo ctx) {
            return amount;
        }
    },
    VIP {
        @Override
        public BigDecimal applyDiscount(BigDecimal amount, OrderInfo ctx) {
            return amount.multiply(new BigDecimal("0.95"));
        }
    };
    
    public abstract BigDecimal applyDiscount(BigDecimal amount, OrderInfo ctx);
}

再引入一个商品类目的枚举，让它自己判断能否参与促销：

java复制public enum ProductCategory {
    NORMAL {
        @Override
        public boolean isPromotionAllowed() {
            return true;
        }
    },
    FRESH {
        @Override
        public boolean isPromotionAllowed() {
            return false;
        }
    };
    
    public abstract boolean isPromotionAllowed();
}

重构后的Service方法明显清爽了很多：

java复制public class OrderService {
    public BigDecimal calculatePayAmount(Order order, User user, boolean isFirstOrder) {
        BigDecimal amount = order.getProductAmount();
        
        if (isFirstOrder) {
            amount = amount.subtract(new BigDecimal("10"));
        }
        
        if (!order.getCategoryEnum().isPromotionAllowed()) {
            return amount;
        }
        
        return user.getLevelEnum().applyDiscount(amount, order.toOrderInfo());
    }
    
    public BigDecimal deductCoupon(Order order, User user, Coupon coupon, boolean isFirstOrder) {
        if (!order.getCategoryEnum().isPromotionAllowed()) {
            return BigDecimal.ZERO;
        }
        if (user.getLevelEnum() == UserLevel.VIP && isFirstOrder) {
            return coupon.getAmount();
        }
        if (isFirstOrder) {
            return BigDecimal.ZERO;
        }
        return coupon.getAmount();
    }
}

第一轮重构后，“商品能否参与促销”这个规则已经收拢到ProductCategory枚举里了。以后新增一个“数码类目不支持优惠券”的需求，只需要改这个枚举，不需要再在其他方法里寻找所有散落的if判断点。

3.3 第二轮重构：策略模式解耦多条件组合规则

第一轮重构解决了一部分问题，但还有一段隐藏的重复：在coupon的核销规则里，出现了“用户等级+是否首单+商品类目”三个条件的组合判断。这种多条件组合的判断逻辑，如果继续用if-else叠加，随着条件增多会变成排列组合。这时就需要引入策略模式。

定义一个优惠券计算策略接口：

java复制public interface CouponDeductPolicy {
    BigDecimal deduct(Order order, User user, Coupon coupon, boolean isFirstOrder);
    boolean support(Order order, User user, Coupon coupon, boolean isFirstOrder);
}

然后创建两个策略实现：

java复制public class FreshCategoryNoCouponPolicy implements CouponDeductPolicy {
    @Override
    public BigDecimal deduct(Order order, User user, Coupon coupon, boolean isFirstOrder) {
        return BigDecimal.ZERO;
    }
    
    @Override
    public boolean support(Order order, User user, Coupon coupon, boolean isFirstOrder) {
        return !order.getCategoryEnum().isPromotionAllowed();
    }
}

public class VipFirstOrderPolicy implements CouponDeductPolicy {
    @Override
    public BigDecimal deduct(Order order, User user, Coupon coupon, boolean isFirstOrder) {
        return coupon.getAmount();
    }
    
    @Override
    public boolean support(Order order, User user, Coupon coupon, boolean isFirstOrder) {
        return user.getLevelEnum() == UserLevel.VIP && isFirstOrder;
    }
}

用策略列表替代原有if-else链：

java复制public class CouponDeductService {
    private List<CouponDeductPolicy> policies;
    
    public CouponDeductService() {
        policies = List.of(new FreshCategoryNoCouponPolicy(), new VipFirstOrderPolicy());
    }
    
    public BigDecimal deduct(Order order, User user, Coupon coupon, boolean isFirstOrder) {
        return policies.stream()
                .filter(p -> p.support(order, user, coupon, isFirstOrder))
                .findFirst()
                .map(p -> p.deduct(order, user, coupon, isFirstOrder))
                .orElse(coupon.getAmount());
    }
}

策略模式的本质，是把“条件判断+执行动作”的复合逻辑封装为独立策略，让每个策略只关注自己的场景。以后新增一种优惠券使用规则时，只需要新增一个策略实现类，放进策略列表即可，不需要改动任何已有策略代码。

3.4 重构效果对比：重复逻辑的去向

两轮重构之后，原来的两个方法中重复的规则被拆成了三个模型：UserLevel枚举承载用户等级折扣规则，ProductCategory枚举承载类目促销规则，CouponDeductPolicy策略族承载优惠券组合规则。

原先在方法里的重复判断现在都变成了对模型的少量调用。同类规则不再有多个副本，新增规则只需要扩展模型。这就是标题里“通过领域模型扩展”的实际显现——不是靠删代码来消除重复，而是靠模型行为替代方法内分支判断，让重复逻辑没有地方可以安身。

重构后的方法，清除了一大部分if-else，方法体的长度大幅缩短。更关键的是，以后凡是遇到“某个类目新的促销限制”“某个用户等级新的折扣率”，都不需要打开OrderService逐个方法排查了，直接在对应模型里修改即可。这种“规则找得到、改得动、测得了”的状态，就是重构要达到的目标。

4. 实操过程里的注意事项与避坑指南

4.1 不要过度设计：提前抽象比不抽象更危险

领域模型重构最容易犯的错误，是在重复尚未出现前就预判抽象。我曾经接手过一个订单系统，前任开发者把用户类型、订单类型、物流方式全部做成了策略模式，一共十几个类。看起来很整齐，但每个策略内部实际只有一行return，而且这些类型在业务上已经稳定了两年，根本不会新增。这十几个类就是纯粹的过度设计，增加了代码阅读负担，没有任何收益。

怎么判断是否过度设计？我在实操中总结了一个原则：至少等到第二次重复出现时再考虑抽象。第一次出现时，先确认这个规则是否独立清晰。第二次出现时，对比两处的实现细节，确定能提炼出公共模型。第二次都没到，就不要动手。如果预判未来一定会出现第三次，可以先把规则沉淀为模型上的一个方法，但不必引入完整的策略模式体系。

4.2 事务边界与框架集成：模型不能替代一切

领域模型承载行为之后，会有一个新的问题：模型方法里能不能直接访问数据库？如果不能在模型里做持久化操作，那原来在Service方法里的事务逻辑该怎么迁移？

我的建议是：模型层只做内存中的计算与规则判断，不做持久化操作。所有需要访问数据库的逻辑仍然留在Service层，通过仓储接口取数据，组装成模型上下文后传给模型方法。模型方法只负责根据传入数据计算或判断，返回结果，不直接操作Repository、不开启事务。

这样的边界划分有几个好处：第一，模型方法变得非常容易被单元测试，不用Mock数据库操作；第二，事务边界始终在Service层，不会因为模型调用而扩大或缩小事务范围；第三，模型的复用性更广，既可以被Service调用，也可以被单元测试、批处理任务等其他入口调用。

在Spring框架集成时，策略对象和枚举模型大多数是纯Java对象，不依赖Spring容器管理，直接用new创建即可。但有些策略实现可能依赖其他Spring Bean，比如优惠券核销策略需要查询优惠券库存。这种情况下，建议让策略实现类本身标注@Component，通过构造器注入依赖，然后用一个策略工厂或直接在Service里通过List<某Policy>的方式注入所有实现。这样做既可以保持策略模式解耦，也解决了框架依赖问题。

4.3 领域模型的命名与位置：别把规则藏在隐晦的方法名里

代码重构后，模型的命名对后续维护影响非常大。我见过不少重构后的代码，枚举方法名叫getResult()、策略方法叫handle()，完全无法从命名上判断业务含义，后来的人只能靠阅读实现细节来理解。

领域模型的方法名应该直接表达业务规则。比如isPromotionAllowed()就比check()清晰，applyDiscount()就比doCalc()好。如果你发现策略类的命名已经无法用一个业务动作概括，那可能是策略粒度太粗，需要继续划分子策略。

模型的存放位置也值得注意。如果是与数据库实体强关联的枚举（如订单状态、用户等级），建议放在实体的同包或子包中，保持领域概念的聚合。如果是纯计算的策略，可以放在独立的业务规则包中，比如com.xxx.order.policy。核心原则是：同类模型的归属位置要一致，让新来的人能够用直觉找到规则的实现位置。

5. 常见问题与排查技巧实录

5.1 重构后行为不一致：如何高效定位回归

重构过程中最让人头疼的问题是：测试环境一切正常，上线后发现某个订单金额计算的结果和之前不一致。排查这类问题，我的经验是首先确认“哪个模型的行为和原来的判断逻辑不一致”。

比如原始的if-else处理顺序可能是“先判断首单，再判断类目，再判断VIP折扣”，而重构后枚举的计算顺序可能是因为方法调用时机不同发生了微妙变化。处理金额时，BigDecimal的舍入方式和计算顺序对结果影响巨大，尤其是涉及乘法、减法多个步骤时更明显。

解决方案是在重构时保留一份“行为对照表”，在代码里旧逻辑和新逻辑同时保留一段时间，通过一个开关（如配置项）控制走哪条路径。然后在测试环境跑一轮全量回归，对每个订单对比两条路径的计算结果，不一致的订单会精确暴露新旧逻辑的差异点。确认无差异后再删除旧逻辑，这个过程在金融相关计算中尤其重要。

5.2 Spring容器中的策略注入：为什么策略列表是空的

Spring项目里用策略模式时，一个高频问题是：在Service里通过List<CouponDeductPolicy>注入策略时，发现列表为空，或者在运行时出现NoSuchBeanDefinitionException。

这个问题的原因通常是策略实现类没有被Spring扫描到。排查步骤很简单：第一，检查策略类是否标注了@Component或其衍生注解；第二，检查所在包是否在主启动类的自动扫描范围内；第三，检查构造方法有没有被Spring容器正常识别——尤其是当你写了多个有参构造方法但没有标注@Autowired时，Spring可能无法选择使用哪个构造器。

另一个容易踩的坑是：策略类依赖的其他Bean还没初始化完成，导致循环依赖报错。解决办法是把策略类中的依赖改为ObjectProvider<T>延迟获取，或者在需要时从ApplicationContext中按需获取，避免启动阶段强制注入。

5.3 单元测试策略：模型方法要测什么、怎么测

重构之后，单元测试的写法也随之变化。模型方法因为不依赖数据库和容器，可以直接构造入参来测试，这比之前的Service层测试要简单得多。

枚举行为的测试思路是：针对每个枚举值构造对应的上下文，断言计算结果是否符合预期。比如测试UserLevel枚举的折扣计算，需要准备普通用户上下文和VIP用户上下文，分别断言原价和95折结果。策略类的测试思路是：针对每个策略的support场景和实际计算场景分别写测试用例，确保策略只处理自己负责的场景，且计算结果正确。

我建议把模型方法的单测覆盖率保持在高位，因为模型是业务规则的最核心载体，它的正确性直接影响整个系统的业务正确性。重构后的Service层反而可以降低测试比重，因为如果模型测试已经覆盖了规则穷举，Service层只需要验证方法的串联顺序和事务行为即可。

6. 延伸：领域模型扩展的进阶应用方向

6.1 从枚举到插件化：让新规则不修改主代码

上面的案例里，策略列表是提前写死的。但在真实的业务系统中，策略经常需要动态扩展。如果你使用的是Spring Boot，可以通过@ConditionalOnProperty或自定义条件注解，让某些策略在特定配置下才生效。这样同一个代码库，通过配置即可在不同客户环境启用不同规则组合。

再进一步，如果不同客户需要完全不同的规则集合，可以结合类路径扫描和SpringFactoriesLoader，实现插件化的策略扩展。新增一个客户规则时，只需要开发一个新的策略类并放入约定的包目录，主流程代码一行不改，即可完成扩展。

6.2 用状态机处理复杂状态流转

如果重复逻辑发生在状态流转场景，比如订单状态、审批流、工单状态，那状态机的价值会非常明显。Spring Statemachine或者自研的简单状态机构造可以满足大多数需求。

状态机的核心价值在于：把“当前状态-事件-动作-下一个状态”的映射关系显式化，避免在Service层用if-else链手写状态流转。这不仅消除了重复逻辑，还把状态流转的合法性和非法流转的提示集中到了一个地方。

我在实际项目中用过Spring Statemachine处理订单状态的多分支流转，比原生的if-else实现要清晰非常多。尤其是涉及“同一状态下多个事件分支”“同一事件在不同状态下响应不同”这类复杂场景，状态机的优势几乎是碾压式的。

6.3 从模型到DDD：面向更完整的领域设计

当你的团队在代码重构过程中积累了大量领域模型、策略、规则的实践经验后，下一步可以考虑导入DDD的分层设计理念。包括划分限界上下文、引入聚合根、仓储模式等。但这一步一定要谨慎推进，因为DDD的上手成本较高，团队没有足够的实践基础就直接引入，很可能变成半吊子设计，反而拖慢开发效率。

我的建议是：先从单个业务模块起步，把重复逻辑收拢到领域模型中，形成完整的模型体系。等团队习惯了这种“让模型承载行为”的开发方式之后，再逐步引入DDD的战术模式，这样才能走得扎实。

7. 最后的几点经验心得

做领域模型重构这些年，我最大的体感是：重构的技术并不难，难的是对业务规则本身的理解。每个if分支背后都对应一个业务规则，在你动手抽象之前，先把这些规则想明白、说清楚，比什么设计模式都重要。

另一个实用的经验是：重构时保持小步快跑，每次只改动一类规则，跑通测试后再进行下一类。不要试图一次性把所有重复逻辑都消除掉，那样改动面过大，定位问题时无从下手。一次重构只解决一个维度的重复，积累下来效果会非常可观。

最后分享一个小技巧：重构前用git创建一个单独的分支，每次重构提交时在commit message里写清楚“迁移了哪条业务规则到哪个模型”。这样后续排查历史问题的时候，可以通过commit message直接定位到规则的归属模型，省去大量从代码反推逻辑的时间。

如果你现在正好面临一段逻辑重复的代码，不妨先按照上面的思路，从最小的重复点开始重构。不需要一次吃成胖子，每消除一处重复，系统就变健康一点。