Java 保險理賠計費引擎選型：規則引擎 vs 動態腳本 vs 決策表

業務複雜度分析

理賠計算典型特徵：

• 多險種差異：醫療門診、住院、重疾、意外等計算邏輯迥異
• 參數化因子：免賠額、賠付比例、封頂線、等待期等可配置參數
• 嵌套條件：如「若為網絡內醫院且累計賠付未超限額則按 90% 賠付，否則 70%」
• 頻繁變更：監管政策、產品迭代導致規則月級更新

三大主流技術方案對比

行業最佳實踐：混合架構

// 分層架構設計
public interface CalculationEngine {
    ClaimResult calculate(ClaimContext ctx);
}

// 1. 核心理算層：Drools 規則引擎
@Component
public class CoreClaimEngine implements CalculationEngine {
    private KieSession kieSession;
    
    @Override
    public ClaimResult calculate(ClaimContext ctx) {
        kieSession.insert(ctx);
        kieSession.fireAllRules();
        return ctx.getResult();
    }
}

// 2. 參數配置層：決策表 (Excel/DB)
@Component
public class ParameterResolver {
    public BigDecimal getReimburseRate(String productCode, String hospitalLevel) {
        // 從決策表查找：產品代碼 + 醫院等級 -> 賠付比例
        return decisionTable.lookup(productCode, hospitalLevel);
    }
}

// 3. 複雜定價層：Groovy 動態腳本
@Component
public class PricingScriptEngine {
    private GroovyShell shell = new GroovyShell();
    
    public BigDecimal executePricing(String script, Map vars) {
        Script compiled = shell.parse(script);
        Binding binding = new Binding(vars);
        return (BigDecimal) compiled.run(binding, binding);
    }
}

// 4. 編排層：責任鏈模式串聯
@Service
public class ClaimCalculationOrchestrator {
    @Autowired List engines;
    
    public ClaimResult calculate(ClaimContext ctx) {
        return engines.stream()
            .reduce(ctx, (c, e) -> e.calculate(c), (a, b) -> b)
            .getResult();
    }
}

規則引擎落地關鍵點

1. 規則建模最佳實踐

// 規則文件：medical_outpatient.drl
rule "門診基礎賠付計算"
when
    $claim : Claim(type == ClaimType.OUTPATIENT, 
                   validAmount > 0,
                   $deductible : deductible,
                   $rate : reimburseRate)
then
    BigDecimal payable = ($claim.getValidAmount().subtract($deductible))
                         .multiply($rate)
                         .setScale(2, RoundingMode.HALF_UP);
    $claim.setPayableAmount(payable.max(BigDecimal.ZERO));
    update($claim);
end

rule "年度累計封頂控制"
when
    $claim : Claim(annualAccumulated + payableAmount > annualLimit)
then
    BigDecimal excess = $claim.getAnnualAccumulated()
                          .add($claim.getPayableAmount())
                          .subtract($claim.getAnnualLimit());
    $claim.setPayableAmount($claim.getPayableAmount().subtract(excess));
    update($claim);
end

2. 熱更新機制

• 規則文件存儲於配置中心 (Nacos/Apollo)
• 監聽變更事件 → 重建 KieBase → 原子切換 KieSession
• 灰度發布：按機構/產品代碼路由不同版本規則

3. 測試驗證體系

@Test
public void testOutpatientCalculation() {
    // Given
    ClaimContext ctx = ClaimContext.builder()
        .type(ClaimType.OUTPATIENT)
        .validAmount(new BigDecimal("1000"))
        .deductible(new BigDecimal("100"))
        .reimburseRate(new BigDecimal("0.8"))
        .annualLimit(new BigDecimal("5000"))
        .annualAccumulated(new BigDecimal("4500"))
        .build();
    
    // When
    ClaimResult result = engine.calculate(ctx);
    
    // Then
    // (1000-100)*0.8 = 720，但年度剩餘額度 500，最終賠付 500
    assertEquals(new BigDecimal("500"), result.getPayableAmount());
}

技術選型決策樹

1. 業務邏輯是否標準化、結構化？ → 是 → 決策表
2. 是否存在複雜嵌套條件、需頻繁變更？ → 是 → 規則引擎
3. 是否需支持用戶自定義公式、個性化定價？ → 是 → 動態腳本
4. 綜合上述 → 混合架構（行業主流方案）

避坑指南

• 規則爆炸：單規則文件超過 500 條需拆分模塊
• 上下文污染：KieSession 必須請求級隔離，禁用全局共享
• 性能陷阱：避免在規則中調用外部服務，預先加載所需數據
• 版本不兼容：規則與領域模型版本強綁定，發布時雙驗證