LKT

Thu, 06 Aug 2026 13:56:09 +0000

LKT

一、先抓住 5 个核心抽象

这类商城容易失控，通常不是业务太复杂，而是把“平台订单、供应商订单、自营订单、代客订单、平台券、店铺券”分别建表，最后形成大量重复逻辑。

建议围绕下面 5 个对象设计：

组织主体 Org：平台、供应商、店铺经营者只是不同角色。
销售报价 Offer：同一个 SKU 在不同店铺、供应商、履约方式下形成不同 Offer。
交易订单 Order：描述谁买、谁下单、买了什么。
金额明细 ChargeLine：商品价、折扣、卡券、积分、运费全部表现为金额行。
履约单 FulfillmentOrder：描述谁发货、从哪里发、如何发。

核心关系可以概括为：

组织 Org
 └─ 店铺 Shop
 └─ 销售报价 Offer
 ├─ SKU
 ├─ 销售方
 ├─ 供应方
 ├─ 履约策略
 └─ 结算策略

交易主单 TradeOrder
 └─ 店铺订单 SellerOrder
 ├─ 订单项 OrderItem
 ├─ 金额行 ChargeLine
 ├─ 履约单 FulfillmentOrder
 └─ 结算行 SettlementLine

二、主体模型：不要分别设计平台表、供应商表、商家表

1. 组织表 `org`

org
---
id
name
legal_name
status
tenant_id -- 多平台/SaaS时使用
created_at

平台、供应商、经销商、店铺经营公司都放在这里。

2. 组织角色表 `org_role`

org_role
--------
id
org_id
role_type -- PLATFORM / SUPPLIER / SELLER / SHOP_OPERATOR /
 -- STOCK_OWNER / SHIPPER / SETTLEMENT_PARTY
scope_type -- GLOBAL / PLATFORM / SHOP
scope_id
status
valid_from
valid_to

一个组织可以同时拥有多个角色。例如平台公司可以同时是：

PLATFORM
SELLER
STOCK_OWNER
SHIPPER

这比在 org 中增加大量布尔字段更灵活。

3. 店铺表 `shop`

shop
----
id
platform_org_id
owner_org_id -- 店铺所有者
operator_org_id -- 实际运营者
name
shop_type
status

自营店铺不需要单独建表：

owner_org_id = platform_org_id
operator_org_id = platform_org_id

供应商店铺则可以是：

owner_org_id = supplier_org_id
operator_org_id = supplier_org_id

4. 组织关系表 `org_relation`

org_relation
------------
id
from_org_id
to_org_id
relation_type -- SUPPLY_TO / OPERATE_FOR / SETTLE_FOR / AGENT_OF
contract_id
valid_from
valid_to
status

用于表示供应关系、代运营关系、代理关系，而不是把这些关系硬编码在组织表中。

三、商品模型：必须区分 SKU 和 Offer

商城中最重要的简化，是把“商品是什么”和“商品怎么卖”分开。

1. 商品基础表

product_spu
-----------
id
name
category_id
brand_id
status

product_sku
-----------
id
spu_id
sku_code
spec_json
weight_gram
volume
status

SKU 只描述商品本身，不直接放店铺、供应商、发货方式和销售价格。

2. 销售报价表 `offer`

offer
-----
id
shop_id
sku_id

seller_org_id -- 法律意义上的销售方
supplier_org_id -- 供货方，可为空
stock_owner_org_id -- 库存所有者

sale_price
market_price

fulfillment_policy_id
settlement_policy_id
freight_template_id

status
version
valid_from
valid_to

offer 是整个商城的关键对象。

同一个 SKU 可以有多个 Offer：

SKU A
├─ 平台自营店销售，平台库存，平台发货
├─ 平台自营店销售，供应商库存，供应商代发
├─ 供应商店铺销售，供应商发货
└─ 另一店铺销售，平台仓发货

不要在 SKU 上放：

is_self_operated
is_supplier_ship
supplier_id
shop_id
sale_price

因为这些属性不是商品属性，而是销售关系属性。

3. 履约策略表

fulfillment_policy
------------------
id
name
fulfillment_mode -- PLATFORM_SHIP / SELLER_SHIP /
 -- SUPPLIER_DROP_SHIP / PICKUP / VIRTUAL
default_shipper_org_id
default_stock_owner_org_id
return_receiver_org_id
allow_split
status
version

“自营”和“发货”是两个不同维度：

场景	seller_org	stock_owner	shipper
平台自营、平台发货	平台	平台	平台
平台自营、供应商代发	平台	供应商	供应商
供应商店铺销售发货	供应商	供应商	供应商
商家销售、平台仓发货	商家	商家或平台	平台

因此，不建议使用单一字段 business_type=SELF/THIRD_PARTY 决定所有逻辑。

四、订单模型：主订单、店铺订单、履约单分开

1. 交易主单 `trade_order`

代表用户的一次提交或支付行为。

trade_order
-----------
id
order_no

buyer_user_id -- 权益和售后归属人
placed_by_user_id -- 实际操作下单的人
order_source -- WEB / APP / AGENT / ADMIN / API

currency
status

goods_amount
discount_amount
freight_amount
payable_amount
paid_amount

address_snapshot_json
created_at
paid_at

代客下单不需要单独建“代客订单表”

只需要：

buyer_user_id = 被代下单的客户
placed_by_user_id = 客服、销售或代理人员
order_source = AGENT

必要时增加订单参与者表：

order_actor
-----------
id
order_id
actor_role -- BUYER / PLACER / RECIPIENT / SALESPERSON /
 -- CUSTOMER_SERVICE / REFERRER
actor_type -- USER / ORG
actor_id
org_id

这样可以支持销售归属、客服归属、推荐人、收货人等，而不用不断往订单表增加字段。

2. 店铺订单 `seller_order`

seller_order
------------
id
trade_order_id
shop_id
seller_org_id
settlement_policy_id
status

goods_amount
discount_amount
freight_amount
payable_amount

一张交易主单可以拆成多个店铺订单。

通常按照下面的组合拆单：

shop_id
+ seller_org_id
+ settlement_policy_id

不要直接按供应商拆交易订单，因为供应商更多是供货和履约角色，未必是销售方。

3. 订单项 `order_item`

order_item
----------
id
seller_order_id

offer_id
spu_id
sku_id

sku_name_snapshot
spec_snapshot_json
image_snapshot
offer_snapshot_json

quantity
unit_list_price
unit_sale_price
item_amount

status

订单中必须保存快照，不能在查看历史订单时重新查询当前商品名称、价格和履约策略。

五、统一金额模型：所有优惠、运费、积分都形成金额行

商城最容易复杂的部分，是在订单表不断增加：

platform_coupon_amount
shop_coupon_amount
points_amount
member_discount_amount
promotion_discount_amount
freight_discount_amount

更好的方式是建立统一金额明细表。

`order_charge_line`

order_charge_line
-----------------
id

trade_order_id
seller_order_id
order_item_id -- 可为空
fulfillment_order_id -- 可为空

scope_type -- ORDER / SELLER_ORDER / ITEM / FULFILLMENT
charge_type -- GOODS / PROMOTION / COUPON / POINTS /
 -- FREIGHT / TAX / SERVICE_FEE / PRICE_ADJUSTMENT

amount -- 正数增加应付，负数减少应付
currency

source_type -- RULE / BENEFIT_ASSET / MANUAL / FREIGHT_RULE
source_id
source_version

bearer_org_id -- 谁承担该优惠
beneficiary_org_id -- 谁最终获得该金额

allocation_method -- 按金额、数量或指定比例分摊
reverse_of_line_id -- 退款冲销时使用
created_at

例如一笔订单：

金额类型	金额	承担方
商品原价	+200	买家
商品促销	-20	店铺
店铺券	-10	店铺
平台券	-5	平台
积分抵扣	-3	平台
运费	+8	买家
最终应付	170	派生结果

订单的汇总金额仍然可以保存在 trade_order 和 seller_order 中，用于查询性能；但它们应当由金额行汇总得到，金额行才是可审计的明细依据。

这样新增“满减券”“新人补贴”“直播间补贴”时，通常只需增加 charge_type 或 source_type，不需要修改订单表结构。

六、营销模型：规则、权益、使用记录三层分离

积分、平台券、店铺券、卡余额、会员折扣不能全部塞进一个促销表，也不应分别写进订单逻辑。

建议分为三层。

第一层：营销规则

marketing_rule
--------------
id
name
rule_type -- DIRECT_DISCOUNT / FULL_REDUCTION /
 -- COUPON_ISSUE / POINTS_EARN / POINTS_REDEEM
issuer_org_id
priority
stack_group
exclusive_group
conditions_json
actions_json
version
valid_from
valid_to
status

适用范围单独建表：

marketing_rule_scope
--------------------
id
rule_id
include_exclude -- INCLUDE / EXCLUDE
scope_type -- PLATFORM / SHOP / CATEGORY / SPU / SKU / OFFER
scope_id

平台券和店铺券使用同一模型：

issuer_org_id：谁发行、谁承担
scope_type/scope_id：在哪些平台、店铺或商品使用

而不是建立 platform_coupon 和 shop_coupon 两套表。

第二层：用户权益定义

benefit_definition
------------------
id
name
benefit_type -- COUPON / POINTS_ACCOUNT / STORED_VALUE_CARD /
 -- DISCOUNT_RIGHT / GIFT_CERTIFICATE
issuer_org_id
face_value
discount_rate
threshold_amount
validity_policy_json
stack_policy
status
version

第三层：用户持有的权益资产

benefit_asset
-------------
id
definition_id
owner_user_id

asset_no
balance
quantity

valid_from
valid_to
status -- AVAILABLE / RESERVED / USED / EXPIRED / FROZEN

举例：

一张优惠券：一条 benefit_asset，数量为 1。
积分账户：一条 benefit_asset，余额为积分数。
储值卡：一条 benefit_asset，余额为金额。
会员折扣权：一条 benefit_asset，表示有效权益。

权益流水

benefit_ledger
--------------
id
asset_id
biz_type -- ISSUE / EARN / RESERVE / COMMIT /
 -- RELEASE / EXPIRE / REFUND / ADJUST
delta
balance_after
biz_id
idempotency_key
created_at

权益占用记录

benefit_reservation
-------------------
id
asset_id
order_id
reserve_amount
used_amount
status -- RESERVED / COMMITTED / RELEASED
expires_at
idempotency_key

标准流程为：

试算 → 锁定权益 → 创建订单 → 支付成功后核销
 └→ 订单取消后释放

不能在创建订单时直接扣掉积分或销毁优惠券，否则支付失败、超时取消时很难恢复。

七、运费模型：运费规则与履约拆单分离

1. 运费模板

freight_template
----------------
id
owner_org_id
name
charge_dimension -- WEIGHT / QUANTITY / VOLUME / FIXED
status
version

2. 运费区域规则

freight_rule
------------
id
template_id
region_group_id

first_unit
first_fee
increment_unit
increment_fee

free_threshold_type -- NONE / AMOUNT / QUANTITY / WEIGHT
free_threshold_value

valid_from
valid_to

统一支持：

按重量计费
按件数计费
固定运费
首重续重
首件续件
满金额包邮
指定地区包邮

运费计算产生一条或多条 order_charge_line，而不是直接把结果写死在订单表。

3. 履约单

fulfillment_order
-----------------
id
seller_order_id

fulfillment_mode
shipper_org_id
stock_owner_org_id
warehouse_id

address_snapshot_json
status

estimated_weight
actual_weight
customer_freight_amount
actual_logistics_cost

4. 履约明细

fulfillment_item
----------------
id
fulfillment_order_id
order_item_id
quantity

5. 包裹与物流

shipment
--------
id
fulfillment_order_id
carrier_code
tracking_no
package_no
status
shipped_at
received_at

履约单建议按以下维度拆分：

shipper_org_id
+ stock_owner_org_id
+ warehouse_id
+ fulfillment_mode
+ 收货地址

一个店铺订单可以拆成多个履约单，一个履约单也可以包含多个订单项。

需要特别区分：

买家支付的运费 customer_freight_amount
实际物流成本 actual_logistics_cost

两者不是同一个概念。

八、库存模型：所有权和仓库必须分开

inventory_balance
-----------------
id
stock_owner_org_id
warehouse_id
sku_id
total_quantity
reserved_quantity
available_quantity
version

inventory_reservation
---------------------
id
order_id
order_item_id
stock_owner_org_id
warehouse_id
sku_id
quantity
status
expires_at
idempotency_key

inventory_ledger
----------------
id
stock_owner_org_id
warehouse_id
sku_id
biz_type
biz_id
quantity_delta
balance_after
created_at

重点是库存键包含：

库存所有者 + 仓库 + SKU

同一个仓库可能代管不同供应商的库存，不能只使用 warehouse_id + sku_id。

九、支付和结算必须分开

支付描述“买家付了多少钱”，结算描述“平台最终应该给谁多少钱”。

1. 支付单

payment_order
-------------
id
trade_order_id
payment_no
payer_user_id
amount
status

payment_transaction
-------------------
id
payment_order_id
channel
channel_transaction_no
transaction_type -- PAY / REFUND
amount
status
idempotency_key

2. 结算明细

settlement_line
---------------
id
trade_order_id
seller_order_id
order_item_id

payer_org_id
payee_org_id

settlement_type -- GOODS_RECEIVABLE / PLATFORM_COMMISSION /
 -- PLATFORM_SUBSIDY / SELLER_DISCOUNT /
 -- FREIGHT / SERVICE_FEE

amount
currency
due_at
status
reverse_of_line_id

例如平台券不应简单理解为“订单少收 10 元”：

买家少支付 10 元；
商家可能仍按原金额收款；
平台需要向商家补贴 10 元。

因此：

order_charge_line

负责解释买家的应付金额；

settlement_line

负责解释平台、店铺、供应商之间如何分钱。

十、几个典型场景如何落到同一套表

场景一：平台自营、平台发货

offer.seller_org_id = 平台
offer.stock_owner_org_id = 平台
fulfillment.shipper_org_id = 平台

场景二：平台销售、供应商代发

offer.seller_org_id = 平台
offer.supplier_org_id = 供应商A
offer.stock_owner_org_id = 供应商A
fulfillment.shipper_org_id = 供应商A

消费者看到的是平台自营，但履约由供应商完成。

场景三：供应商店铺销售

shop.owner_org_id = 供应商A
offer.seller_org_id = 供应商A
fulfillment.shipper_org_id = 供应商A

场景四：客服代客下单

trade_order.buyer_user_id = 客户
trade_order.placed_by_user_id = 客服
trade_order.order_source = AGENT

积分、优惠券、售后权益都归 buyer_user_id，操作审计归 placed_by_user_id。

场景五：平台券

benefit_definition.issuer_org_id = 平台
rule_scope.scope_type = PLATFORM
charge_line.bearer_org_id = 平台

场景六：店铺券

benefit_definition.issuer_org_id = 店铺经营组织
rule_scope.scope_type = SHOP
rule_scope.scope_id = 店铺ID
charge_line.bearer_org_id = 店铺经营组织

十一、推荐的最小核心表集合

第一阶段不必一次建设完整体系，可以先落下面这些核心表：

主体
1. org
2. org_role
3. shop

商品
4. product_spu
5. product_sku
6. offer
7. fulfillment_policy

交易
8. trade_order
9. seller_order
10. order_item
11. order_actor
12. order_charge_line

营销
13. marketing_rule
14. marketing_rule_scope
15. benefit_definition
16. benefit_asset
17. benefit_ledger
18. benefit_reservation

履约与库存
19. freight_template
20. freight_rule
21. fulfillment_order
22. fulfillment_item
23. shipment
24. inventory_balance
25. inventory_reservation

资金
26. payment_order
27. payment_transaction
28. settlement_line

复杂度较低的项目，可以先不建立完整库存流水和结算批次，但 order_charge_line、benefit_ledger 和 settlement_line 建议从一开始就保留。

十二、落地时最重要的约束

1. 规则必须版本化

修改营销规则、运费模板、履约策略时创建新版本，不覆盖旧版本。

订单记录：

rule_id
rule_version
policy_id
policy_version

历史订单不能使用当前规则重新计算。

2. 金额统一使用最小货币单位

人民币使用“分”：

amount = 1999

表示 19.99 元，避免浮点误差。

重量统一使用克，折扣可以用万分比：

discount_rate = 8500

表示 85 折。

3. 退款采用反向流水

不要直接修改原始金额行、库存流水、权益流水。

通过：

reverse_of_line_id

生成负向记录，保证完整审计链。

4. 所有锁定和扣减都要有幂等键

包括：

库存锁定
积分扣减
卡券核销
支付回调
退款
结算

使用：

idempotency_key

防止支付渠道和消息队列重复回调。

5. JSON 只能用于规则和快照

适合放 JSON 的内容：

营销条件和动作
商品规格快照
地址快照
履约策略快照

不适合放 JSON 的内容：

金额
状态
店铺和组织关系
库存数量
结算关系
核心查询条件

6. 核心关系使用明确外键

source_type + source_id 这种多态引用，只适合金额流水、操作日志、事件记录等附属表。核心对象之间应使用明确字段和外键，避免建设一张万能业务表。

最终建议

真正能够简化系统的不是减少表数量，而是减少业务分支：

平台、供应商、店铺统一为组织和角色；
自营、代销、代发统一由 Offer 中的销售方、库存方、发货方组合表达；
平台券、店铺券统一为发行方 + 使用范围 + 承担方；
代客下单统一为购买人和操作人分离；
商品价、积分、卡券、折扣、运费统一为金额行；
订单、发货、支付、结算各自独立，通过订单项关联。

其中最值得优先设计正确的三张表是：

offer
order_charge_line
settlement_line

这三张表设计稳定后，后续增加直播带货、渠道代理、供应商代发、平台补贴、组合优惠和多仓履约时，通常不需要推翻订单主模型。

墨笺文档

LKT

LKT