背景
上篇說過訂單基礎設計，介紹了訂單中心應該有哪些能力，大概有哪些字段，還有容量上的處理。上篇有點像在講訂單的數據模型，這篇來看看訂單的業務模型。
價格模型
訂單的價格怎麼計算得來？普通電商平臺用戶 實付 = 商品原價 * 商品數量 - 優惠 - 抵扣 + 運費。
抵扣是啥？抵扣其實就是一種平臺給予用戶的等價物，類似於只能在特定平臺使用的錢。例如：淘寶（淘金幣）、京東（京豆）
抵扣爲啥不和優惠合併？在業務初期其實抵扣和優惠並無區別，但當具有一定規模時，抵扣可以作爲一種單獨的業務域獨立的發展運行，相對於優惠僅限商品購買，抵扣可能會有更多的獨立的玩法，因此參考與業界的作法將其脫離優惠，單獨計算。
優惠具體有啥？優惠其實到了促銷域，訂單需要感受一些促銷相關的概念，作爲資深的電商購物者，大家平時淘寶、京東下單時，也能發現優惠的許多種類，整理一下可得大致的優惠類別：
屬於電商平臺級別優惠：
- 平臺優惠（滿n件打折、滿n元/件立減、跨店滿減）
- 平臺優惠券（全場可用、指定商家滿n元/件可用、打折、立減）
- 會員優惠（88vip、京東plus）
屬於店鋪級別優惠：
- 店鋪優惠（滿n件打折、滿n元/件立減）
- 店鋪優惠券（立減，打折）
屬於商品級別優惠：
- 商品優惠（打折、立減、一口價）
是不是對應的訂單三級模型？所以你對整體業務瞭解的越多，那麼你的設計一定是越合理的。
每個級別的訂單存儲對應級別的優惠，這裏還會涉及優惠的分攤，分攤在文章末尾會附加說明。
一次交易行爲到底有多少個價格呢？簡單列一下
- 訂單原價（商品原價 * 購買數量）
- 用戶實付（商品原價 * 購買數量 - 優惠 - 抵扣 + 運費）
- 賣家實收（商品原價 * 購買數量 - 店鋪出資優惠 + 運費）
- 平臺實收 (賣家實收 * 服務費比例)
針對這麼多種價格，訂單模型絕不是存儲每種價格的結果就行了，之後業務若還有其他需求，那不是豈要新加字段？
其實分析下來影響價格的因子就這些：商品原價 、 商品數量 、 優惠 、 抵扣 、 運費。
只要有基礎的因子，其他的價格也就是在此基礎上進行組合。
延伸：分攤
如果你買了A（10元）1件，B（8元）1件，C（3元）1件，三個商品，用了一張滿全平臺通用滿10-5的優惠券。
A、B、C三個商品均在不同的店鋪，那麼在一起支付完之後，平臺會按照店鋪的維度進行拆單，用戶將看到三筆訂單。
那麼就涉及到分攤了，分攤即將上級優惠、抵扣、費用，進行價格權重分到下一級中。此處我們的都是基於訂單，因此平臺級別分攤到店鋪級，店鋪級別分攤到商品級。
分攤方案1：對每個訂單進行價格權重計算，結果四捨五入。
A商品級訂單分攤到的優惠就是 10/(10+8+3) * 5 ≈ 2.38
B商品級訂單分攤到的優惠就是 8/(10+8+3) * 5 ≈ 1.90
C商品級訂單分攤到的優惠就是 3/(10+8+3) * 5 ≈ 0.71
因爲平臺支持的金額精度是到分，因此四捨五入到分，如果每位都如此計算，那麼分攤總數相加很有可能不等於被分攤數。
上例最終 2.38 + 1.90 + 0.71 = 4.99 < 5
分攤方案2：對商品級訂單排序，價格低的優先分攤，還是使用價格權重計算，最後一筆訂單使用總金額 - 已分攤數，進行補齊。
C商品級訂單分攤到的優惠就是 3/(10+8+3) * 5 ≈ 0.71
B商品級訂單分攤到的優惠就是 8/(10+8+3) * 5 ≈ 1.90
A商品級訂單分攤到的優惠就是 5-(0.71 + 1.90) = 2.39
這樣下的分攤結果幾乎就不會產生問題了。