業務邏輯開發套路的三板斧

轉自：代碼這件大事

背景：

作爲一個研發，我們工作中都會處理面臨下面這些困惑：

又加需求，一個方法本來就處理了 300 行，現在又加 50 行。
狀態邏輯太多了，產品第 2 期又加了一個邏輯，代碼結構要調整，很頭疼。
每個人都在吐槽，業務研發在工作中處理最多的就是 if else，好不容易寫個 switch 都能給同事吹一週。以上三個場景應該是日常需求迭代優化中面臨最多的場景了，作爲一個自稱編碼水平較高的人，總結了以下三個真實的場景，給出一些可選的方案。

第一板斧：抽象事件，驅動業務

核心

梳理產品邏輯中的主流程節點，整理節點所需要的依賴數據已經節點觸發後對應的業務邏輯。類比消息隊列，也是不同的業務方訂閱自己的事件源，進行不同的處理。不同點在於一個是分佈式，一個是本文描述單機業務處理場景。

實際例子

舉一個用戶註冊之後的場景，需要：

發短信
發優惠券如果用戶註冊成功之後，直接發了mq消息，那麼用戶系統和券系統分別訂閱這個消息進行處理。不過這裏討論的是在一個項目模塊中處理完所有相關的邏輯。

代碼將在 UserRegistered() 中一步一步去處理邏輯，之後需求又加入了 初始化A數據和初始化B數據 兩個需求，實現也會落到這個方法之後，最後整個代碼會越來越臃腫。

接下來用事件訂閱模型去化解這個點，非常實用，一點都不華麗，代碼也很好讀懂。

最後對應到程序代碼可能是這樣的：

# 事件註冊
Event::register(UserRegistered::class, [
    SendSms::class,
    SendCoupon::class,
    InitSystemA::class,
    InitSystemB::class,
]);

# 業務調用
handleRegistered($user) {
    $event = new UserRegistered($user);
    $event->fire();
}

後面的迭代維護中，只要主流程不發生變化，那麼相應的邏輯只需要去增加訂閱者去實現。

第二板斧：有限狀態機，定義流程

在業務邏輯數據處理這一層，很多的業務場景都與數據扭轉狀態有關，並且最後會有相應的數據實體相映射。比如我們常見的：

各種商品訂單（天貓，淘寶，外賣）
工作流（審批，工單處理）

這類需求的特點是，讀寫場景QPS不高，對數據的準確一致性要求非常高。我們底層一般直接存儲到數據庫，之上加一層簡單的數據緩存就能處理。

面臨的主要問題是，狀態太多難以維護，應該還會出現狀態的調整比如特殊場景下的狀態A到狀態Z的扭轉。

不過業內早已給出了比較通用的解決方案，有限狀態機。下面我們列舉一個簡單的訂單狀態扭轉邏輯：

fsm := fsm.NewFSM(
    "created",
    fsm.Events{
        {Name: "pay", Src: []string{"created"}, Dst: "paid"},  //支付
        {Name: "cancel", Src: []string{"created"}, Dst: "closed"}, //關閉
    },
    fsm.Callbacks{
        "after_pay": func(e *fsm.Event) { /* 支付成功調用 */ },
    },
)

如果設計到狀態相關的調整，在狀態機定義的地方去修改就可以解決問題。和事件訂閱非常相識，也是集中維護，統一管理。