系统基础服务

订单服务边界划分

明确订单服务的功能范围是设计的第一步。订单服务需要涵盖三个核心功能：基本信息管理、订单优惠管理和订单生命周期管理。

基本信息管理包括订单的基础增删改查功能，涉及用户、商品、收货信息等通用字段，同时需支持不同渠道的特定信息存储。

订单优惠管理负责存储和展示订单的费用组成，包括折扣和减免信息，但优惠计算逻辑由外部促销系统处理。

订单生命周期管理需设计通用的状态机制，支持不同行业和渠道的状态流转需求，通过主状态和子状态的结合实现灵活性与规则控制。

服务边界排除项

为避免职责模糊，需明确以下功能不属于订单服务：

订单服务不主动调用其他服务（如用户或商品服务），由上层应用或聚合服务整合信息。

不直接与第三方系统（如外卖平台或收银系统）集成，相关同步逻辑由独立程序处理。

不包含优惠计算或成本分摊逻辑，仅存储优惠结果供后续系统使用。

不提供详细的物流履单信息，仅存储外部单据号（如配送单号）供关联查询。

订单服务内部设计

状态管理方案

主状态与子状态结合是推荐方案：

• 主状态由服务定义核心状态机（如待支付、已接单、配送中、已完成），控制状态流转规则。
• 子状态开放给应用自定义（如配送中可细化为“仓库发货”“快递员送货”），满足业务灵活性。

接口设计原则

同步接口需分层设计：

• 粗粒度接口：返回核心字段（订单编号、状态、金额等）。
• 中粒度接口：扩展常用字段（如收货地址、商品概要）。
• 细粒度接口：提供完整订单详情（含优惠明细、渠道信息等）。

异步通知通过消息队列实现，实时推送订单状态变更事件。

数据模型示例

订单表需包含以下关键字段：

CREATETABLEorders(order_idVARCHAR(36)PRIMARYKEY,user_idVARCHAR(36),channelENUM('小程序','外卖平台','POS'),main_statusENUM('待支付','已接单','配送中','已完成','已取消'),sub_statusVARCHAR(50),total_amountDECIMAL(10,2),discount_amountDECIMAL(10,2),payment_amountDECIMAL(10,2),delivery_noVARCHAR(50)-- 外部配送单号);

实施建议

1. 领域驱动设计：通过事件风暴工作坊明确业务场景和状态流转规则。
2. 防腐层：在同步程序中隔离第三方系统差异，避免污染订单服务。
3. 版本控制：采用语义化版本管理接口变更，确保向后兼容。

通过明确边界与分层设计，订单服务可兼顾复用性与扩展性，支撑多业务场景需求。