天天看點

通過狀态機優化民宿訂單系統1 有限狀态機的概念2 民宿業務背景3 民宿業務下的訂單狀态4 使用FSM對狀态進行優化

| 目前狀态→ 條件↓ | 狀态a | 狀态b | 狀态c |

| 條件x | ... | ... | ... |

| 條件y | ... | 狀态c | ... |

| 條件z | .. . | ... | ... |

民宿作為新興的一種住宿業态與酒店的預定機制不同,民宿的房東會根據房客的基本情況決定是否允許房客入住,即房東要确認房客的訂單才能成交。

民宿訂單系統作為中間平台既要支撐房源售賣方對自營房源的售賣又要支援對供應商房源的售賣;又要同時作為房源提供商将房源進行分銷。

另外,為了考慮房客感受,訂單系統要支付1)先支付後确認;2) 先确認後支付兩種下單模式。

在複雜的業務背景下導緻訂單的狀态比較多且狀态的流轉複雜,訂單狀态變化的觸發點非常多。

由于考慮到之後民宿業務的擴充(比如可能接入保險等業務),訂單設計時采用訂單項的方式。orderheader表示訂單頭資訊,每個業務存儲在orderitem中作為訂單項存在。

針對民宿的業務場景設計出訂單的狀态如下:

主訂單(orderheader)狀态枚舉

進行中

成功

失敗

訂單取消

訂單部分取消

訂單完成

訂單關閉

房源業務子訂單(spaceorderitem)枚舉 房源訂單狀态 可以拆分為支付線和業務線來看,前半部分代表支付狀态,後半部分代表業務狀态。支付狀态和業務狀态的枚舉做笛卡爾積是邏輯上可能存在的所有狀态清單。實際中隻有下面的狀态才是合法狀态。

待支付待下單

待支付下單失敗

待支付待确認

待支付已确認

待支付确認失敗(拒單)

待支付确認失敗(逾時)

待支付已退訂

已支付待下單

已支付待确認

已支付已确認

待退款下單失敗

待退款确認失敗(拒單)

待退款确認失敗(逾時)

待退款已退訂

待退款部分退訂

部分退款部分退訂

部分退款已确認

已退款下單失敗

已退款确認失敗(拒單)

已退款确認失敗(逾時)

已退款已退訂

訂單狀态的觸發場景枚舉. 下面的枚舉場景是經過抽象的,實際業務場景中遠遠多于下面的7種

建立訂單

訂單支付成功

訂單退款成功

訂單被主動拒絕

訂單被主動接受

訂單确認逾時

訂單被主動取消

訂單狀态被觸發時除了上面枚舉的觸發場景,還要結合當時訂單的具體形态,比如是否為分銷訂單、是否為詢單模式等綜合判斷。影響訂單狀态判斷的條件枚舉如下:

是否已經支付

是否為分銷訂單

是否為自營訂單

是否為詢單模式

考慮到上面枚舉的各種訂單狀态類型以及複雜的訂單狀态變遷觸發節點(上面枚舉了7種,實際業務場景中要多得多),如果将訂單狀态的變化分步到具體每個觸發的事件中會導緻訂單狀态變化的不可控且極易導緻狀态變化的混亂。

此外,狀态的遷移變化,請自行補腦 if... else ...

通過狀态機優化民宿訂單系統1 有限狀态機的概念2 民宿業務背景3 民宿業務下的訂單狀态4 使用FSM對狀态進行優化
封裝狀态機的三個要素1)狀态 2)事件 3)動作
用于具體狀态變遷時的邏輯判斷

關于作者

java菜鳥。聯系方式[email protected] or [email protected]