很多人在做跑腿系统开发时，一开始只考虑“帮买”“帮送”两种业务。但当平台开始发展，很快就会出现：
- 代排队
- 代办证件
- 同城急送
- 商家专送
- 定时取件
- 企业批量派单
如果系统一开始的业务模型设计不具备扩展性，后期每增加一个业务类型，就要大改数据库结构和订单流程。
真正成熟的跑腿系统，核心不在于功能多，而在于模型是否支持持续扩展。
下面讲一个可落地的多业务模型设计方案。
一、核心思路：订单抽象，而不是业务堆砌
很多系统的问题在于：为每种业务单独建表。
例如：
- errand_buy_order
- errand_queue_order
- errand_delivery_order
这种方式短期开发很快，但长期一定失控。
正确做法是：
统一订单模型 + 业务扩展字段 + 策略驱动逻辑。
二、统一订单核心模型设计
1. 数据库结构设计
CREATE TABLE orders (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
order_no VARCHAR(64) NOT NULL,
user_id BIGINT NOT NULL,
business_type VARCHAR(32) NOT NULL,
status INT NOT NULL,
total_amount DECIMAL(10,2),
create_time DATETIME,
update_time DATETIME
);
这里的关键是 business_type 字段。
例如：
- BUY
- DELIVERY
- QUEUE
- AGENCY
所有业务共用一套订单主表。
2. 业务扩展表设计
不同业务的特殊字段，放入扩展表。
CREATE TABLE order_ext_buy (
order_id BIGINT,
goods_name VARCHAR(255),
shop_address VARCHAR(255),
FOREIGN KEY (order_id) REFERENCES orders(id)
);
CREATE TABLE order_ext_delivery (
order_id BIGINT,
pickup_address VARCHAR(255),
receiver_address VARCHAR(255),
weight DECIMAL(8,2),
FOREIGN KEY (order_id) REFERENCES orders(id)
);
这样新增业务时，只需要增加扩展表，而不影响核心订单结构。
三、策略模式实现业务解耦
数据库设计解决了结构问题，业务逻辑如何优雅扩展？
答案是：策略模式。
1. 定义统一业务接口
public interface BusinessHandler {
void validate(CreateOrderRequest request);
BigDecimal calculatePrice(CreateOrderRequest request);
void afterCreate(Order order);
}
2. 不同业务实现不同策略
@Component("BUY")
public class BuyBusinessHandler implements BusinessHandler {
@Override
public void validate(CreateOrderRequest request) {
if (request.getShopAddress() == null) {
throw new RuntimeException("商家地址不能为空");
}
}
@Override
public BigDecimal calculatePrice(CreateOrderRequest request) {
return new BigDecimal("5.00"); // 基础跑腿费
}
@Override
public void afterCreate(Order order) {
// 保存买单扩展数据
}
}
@Component("DELIVERY")
public class DeliveryBusinessHandler implements BusinessHandler {
@Override
public void validate(CreateOrderRequest request) {
if (request.getPickupAddress() == null) {
throw new RuntimeException("取件地址不能为空");
}
}
@Override
public BigDecimal calculatePrice(CreateOrderRequest request) {
return new BigDecimal("8.00");
}
@Override
public void afterCreate(Order order) {
// 保存配送扩展数据
}
}
3. 工厂类动态分发
@Service
public class BusinessFactory {
@Autowired
private Map<String, BusinessHandler> handlerMap;
public BusinessHandler getHandler(String businessType) {
return handlerMap.get(businessType);
}
}
4. 创建订单主流程
public Order createOrder(CreateOrderRequest request) {
BusinessHandler handler = businessFactory.getHandler(request.getBusinessType());
handler.validate(request);
BigDecimal price = handler.calculatePrice(request);
Order order = new Order();
order.setBusinessType(request.getBusinessType());
order.setTotalAmount(price);
orderRepository.save(order);
handler.afterCreate(order);
return order;
}
新增业务类型时，只需要：
- 新增一个 Handler
- 新增一个扩展表
- 不需要修改核心流程
这才是真正可扩展的架构。
四、定价模型的扩展设计
如果价格规则越来越复杂怎么办？
可以引入规则引擎或表达式计算。
例如使用简单公式存储在数据库：
CREATE TABLE pricing_rule (
business_type VARCHAR(32),
formula VARCHAR(255)
);
示例公式：
base_fee + distance * 1.2
然后使用表达式引擎解析：
ExpressionParser parser = new SpelExpressionParser();
Expression exp = parser.parseExpression(formula);
StandardEvaluationContext context = new StandardEvaluationContext();
context.setVariable("distance", 3.5);
context.setVariable("base_fee", 5);
BigDecimal result = exp.getValue(context, BigDecimal.class);
这样价格策略也具备可扩展能力。
五、未来扩展方向
当业务复杂到一定程度，可以进一步演进：
- 订单核心服务独立成微服务
- 业务策略模块化拆分
- 支持插件式业务加载
- 引入事件驱动架构（Kafka / RocketMQ）
但前提是，你的核心模型必须是抽象的，而不是为某一个业务定制的。
六、总结
跑腿系统开发真正难的不是页面，不是接口数量，而是模型是否能支撑未来三年的扩展。
如果你今天为了图快，把每个业务都独立建一套逻辑，未来一定重构。
如果你一开始就做好：
统一订单模型
扩展字段隔离
策略模式解耦
规则引擎定价
那系统会越做越稳，而不是越做越乱。
架构的价值，不在于炫技，而在于让未来的新增业务几乎零成本接入。
这才是一个成熟跑腿系统应该具备的底层能力。
