电商项目中订单流程可以使用哪些设计模式？如何开发？

CRMEB系统商城

637人浏览 · 2026-03-26 17:30:43

CRMEB系统商城 · 2026-03-26 17:30:43 发布

在电商系统开发中，订单流程是最核心、最复杂的业务模块之一。从用户下单到支付成功，从发货履约到售后处理，一个订单的生命周期要经历数十个状态变更、多次库存操作、多系统协同。如果代码写成了“面条式”的if-else嵌套，不出三个月，维护成本就会高到让开发团队崩溃。

这时候，设计模式就成了拯救订单流程的利器。本文将从实战角度出发，拆解订单流程中高频使用的几种设计模式，并结合CRMEB这类成熟开源系统的实践，告诉你如何把它们真正落地。

一、状态模式：让订单状态流转告别if-else

订单最显著的特征是什么？有状态。

待付款、已付款、已发货、已完成、已取消、售后中……每个状态能做什么操作、不能做什么操作，规则完全不同。如果用最原始的方式写代码：

java

if (order.getStatus().equals("WAIT_PAY")) {
    // 处理取消
} else if (order.getStatus().equals("PAID")) {
    // 处理退款
} else if (order.getStatus().equals("SHIPPED")) {
    // 处理退货
}

这种写法的问题是：每增加一个状态，就要修改所有涉及状态判断的方法；每增加一个操作，就要在原有代码上继续堆砌if-else。几个月后，代码就变成了无人敢动的“屎山”。

状态模式的解决思路是：把状态和对应的行为封装成独立的类。订单只持有当前状态对象，具体的操作委托给状态对象执行。

如何实现？

以CRMEB多商户系统为例，订单状态包含“待付款”“已付款”“已发货”等十几种状态。用状态模式实现的核心代码结构如下：

java

// 订单上下文
public class Order {
    private OrderState state;
    
    public void setState(OrderState state) {
        this.state = state;
    }
    
    public void pay() {
        state.pay(this);
    }
    
    public void cancel() {
        state.cancel(this);
    }
}

// 状态接口
public interface OrderState {
    void pay(Order order);
    void cancel(Order order);
}

// 具体状态：待付款
public class WaitPayState implements OrderState {
    public void pay(Order order) {
        // 处理支付逻辑
        order.setState(new PaidState());
    }
    
    public void cancel(Order order) {
        // 处理取消逻辑
        order.setState(new CancelledState());
    }
}

// 具体状态：已付款
public class PaidState implements OrderState {
    public void pay(Order order) {
        throw new IllegalStateException("已支付订单不能重复支付");
    }
    
    public void cancel(Order order) {
        // 处理退款逻辑
        order.setState(new RefundingState());
    }
}

优势：新增状态时只需添加新类，无需修改现有代码，完全符合“开闭原则”。CRMEB的订单模块正是采用类似的状态机设计，确保了数十万订单的稳定流转。

二、策略模式：让优惠计算变得灵活可配

电商订单的另一大痛点：优惠规则千变万化。

满减、折扣、优惠券、积分、会员价……每种优惠的计算逻辑不同，而且组合规则随时可能调整。如果用if-else实现，每次新增活动类型都要改核心代码，风险极高。

策略模式的解决思路是：把每种优惠算法封装成独立的策略类，让它们可以互相替换。

如何实现？

CRMEB的优惠计算逻辑就采用了类似的设计。以商品到手价为例，系统需要同时处理优惠券、会员折扣、满减活动等多种优惠的叠加计算。用策略模式实现：

java

// 优惠策略接口
public interface DiscountStrategy {
    BigDecimal calculate(BigDecimal originalPrice, OrderContext context);
}

// 具体策略：满减
public class FullReductionStrategy implements DiscountStrategy {
    public BigDecimal calculate(BigDecimal price, OrderContext context) {
        // 满200减30的逻辑
        if (price.compareTo(new BigDecimal("200")) >= 0) {
            return price.subtract(new BigDecimal("30"));
        }
        return price;
    }
}

// 具体策略：会员折扣
public class MemberDiscountStrategy implements DiscountStrategy {
    public BigDecimal calculate(BigDecimal price, OrderContext context) {
        User user = context.getUser();
        // 黄金会员9折
        if ("GOLD".equals(user.getLevel())) {
            return price.multiply(new BigDecimal("0.9"));
        }
        return price;
    }
}

// 订单服务
public class OrderService {
    private List<DiscountStrategy> strategies;
    
    public BigDecimal calculateFinalPrice(Order order) {
        BigDecimal price = order.getOriginalPrice();
        for (DiscountStrategy strategy : strategies) {
            price = strategy.calculate(price, order.getContext());
        }
        return price;
    }
}

CRMEB在处理到手价时，支持区分会员等级展示专属价格，还能自定义优惠优先级。这种灵活性正是策略模式的典型应用——商家可以在后台配置优惠规则，系统动态加载对应的策略实现。

三、观察者模式：解耦订单后的“连锁反应”

订单支付成功后，会发生一系列事情：扣减库存、发送短信、赠送积分、推送物流、更新统计数据……如果把这些代码全写在支付成功的if块里，订单服务会变得臃肿不堪，而且每次新增“支付后要做什么”都得修改核心代码。

观察者模式（也称发布-订阅模式）的解决思路是：订单支付成功时只发布一个“事件”，让感兴趣的“监听器”自己去处理。

如何实现？

CRMEB采用消息队列处理高并发下的订单流转，这正是观察者模式的大规模应用。简化版实现：

java

// 事件定义
public class OrderPaidEvent {
    private Order order;
    private Date paidTime;
    // getter/setter
}

// 事件发布者
public class OrderPublisher {
    private List<OrderPaidListener> listeners = new ArrayList<>();
    
    public void publish(OrderPaidEvent event) {
        for (OrderPaidListener listener : listeners) {
            listener.onOrderPaid(event);
        }
    }
}

// 监听器接口
public interface OrderPaidListener {
    void onOrderPaid(OrderPaidEvent event);
}

// 具体监听器：库存服务
public class InventoryListener implements OrderPaidListener {
    public void onOrderPaid(OrderPaidEvent event) {
        // 扣减库存
    }
}

// 具体监听器：短信服务
public class SmsListener implements OrderPaidListener {
    public void onOrderPaid(OrderPaidEvent event) {
        // 发送发货提醒
    }
}

在实际的高并发场景中，CRMEB使用消息队列（如RabbitMQ、Kafka）来实现异步解耦，订单服务只负责发布事件，库存、积分、短信等服务各自监听处理。这样即使某个下游服务暂时不可用，也不会影响订单主流程。

在CRMEB的订单售后场景中，当用户申请退款时，系统需要同时处理：拦截WMS发货指令、冻结佣金计算、通知商家审核等多个动作。观察者模式让这些逻辑清晰解耦，每个关注“退款申请事件”的模块独立处理自己的逻辑。

四、工厂模式：创建复杂订单对象的“流水线”

一个订单对象的创建涉及：生成订单号、计算价格、记录快照、关联优惠信息、初始化状态……如果直接在Controller里new Order()，然后set这set那，代码会非常混乱。

工厂模式的解决思路是：把订单的创建逻辑封装到专门的工厂类中。

如何实现？

java

public class OrderFactory {
    
    public static Order createFromCart(Cart cart, User user, Address address) {
        Order order = new Order();
        order.setOrderNo(generateOrderNo());
        order.setUserId(user.getId());
        order.setStatus(OrderStatus.WAIT_PAY);
        order.setTotalPrice(cart.calcTotalPrice());
        order.setFreight(calcFreight(address, cart.getTotalWeight()));
        order.setReceiverInfo(address);
        
        // 创建订单快照（商品信息存档，防止后续修改）
        List<OrderItem> items = createOrderItems(cart.getItems());
        order.setItems(items);
        
        // 计算优惠
        DiscountResult discount = calcDiscount(cart, user);
        order.setDiscountAmount(discount.getAmount());
        order.setCouponId(discount.getCouponId());
        
        // 锁定库存
        lockStock(items);
        
        return order;
    }
    
    private static String generateOrderNo() {
        // 生成唯一订单号：时间戳+随机数+用户ID后几位
        return "ORD" + System.currentTimeMillis() + RandomUtil.randomNumbers(4);
    }
}

在CRMEB中，订单创建涉及多种场景：普通购买、拼团订单、秒杀订单、积分兑换等。每种订单的创建逻辑略有差异，通过多个工厂方法或专门的工厂类来封装，既保证了代码复用，又让主流程保持清晰。

五、实战：CRMEB订单模块的设计模式落地

理论讲完，我们来看看CRMEB在实际开发中是如何运用这些设计模式的。

1. 订单状态机设计

CRMEB的订单状态管理采用了有限状态机模型，每个状态都有明确的允许操作和禁止操作。例如：

待付款状态：允许取消、允许支付
已付款状态：允许发货、允许退款
已发货状态：允许确认收货、允许退货

这种设计避免了状态流转的混乱，保证了订单数据的完整性。后台订单列表支持按状态筛选、批量操作，底层正是依赖这套清晰的状态定义。

2. 分单发货的策略实现

CRMEB多商户系统支持“分单发货”——一个订单中的多个商品可以分多个快递发出。这背后是拆单策略的应用：

java

// 拆单策略接口
public interface SplitOrderStrategy {
    List<SubOrder> split(Order order);
}

// 按商户拆单（多商户场景）
public class MerchantSplitStrategy implements SplitOrderStrategy {
    public List<SubOrder> split(Order order) {
        // 按商品归属商户分组，生成子订单
    }
}

// 按仓库拆单（多仓发货场景）
public class WarehouseSplitStrategy implements SplitOrderStrategy {
    public List<SubOrder> split(Order order) {
        // 按商品所在仓库分组
    }
}

// 按商品属性拆单（如易碎品单独包装）
public class AttributeSplitStrategy implements SplitOrderStrategy {
    public List<SubOrder> split(Order order) {
        // 特殊商品单独拆单
    }
}

订单服务根据业务场景选择合适的拆单策略，甚至可以组合使用——先按商户拆，再按仓库拆。

3. 售后流程的观察者模式

在CRMEB的售后流程中，当用户申请退款时，系统需要同时处理多个动作：

通知商家审核
锁定该订单的佣金计算
如果商品未发货，拦截发货指令
记录售后日志

通过观察者模式，这些逻辑被解耦到各自的监听器中，售后主流程只负责“发布退款申请事件”，具体的处理交给各个监听器。

4. 电子面单的工厂封装

CRMEB支持电子面单发货，对接了多家快递公司。每家快递公司的面单接口参数不同，但业务逻辑相似。通过工厂模式封装：

java

public interface ExpressBillFactory {
    ExpressBill createBill(Order order, ExpressConfig config);
}

public class SFExpressBillFactory implements ExpressBillFactory {
    public ExpressBill createBill(Order order, ExpressConfig config) {
        // 顺丰面单生成逻辑
    }
}

public class YTOExpressBillFactory implements ExpressBillFactory {
    public ExpressBill createBill(Order order, ExpressConfig config) {
        // 圆通面单生成逻辑
    }
}

业务代码只需要根据配置的快递公司，获取对应的工厂实例，调用统一接口即可，无需关心具体实现差异。