多種金物流 流程的抽象化與設計 看完 實在覺得 好複雜好多抽象
其實 複雜的優惠邏輯 用 domain model 漂亮建立、測試 我喜歡
但 存進資料庫、呼叫副作用 這些 我覺好像不用太多抽象化
因為我還是要去實際跑一次、看資料庫、看 api 觸發狀況 才有安全感
那樣的話 金物流這部分 我感覺 各自一個 flow 走到底 可能還比較好看懂、好維護
我這看法 我的個性 你懂嗎?
甚至 我發現 好像不需要金物流排列組合
各種金流 各自 flow 就可以了
物流資訊只是存下來 後台人工處理
未來才需要把物流自動整合外部 那樣也只是 api side effect
主要訂單送出 還是接著付款 這樣而已
你有看法嗎?
懂,而且我覺得你這個直覺是對的,不是妥協。
一句話:當你會在 runtime 真的多型切換、而且分支還會一直長時。促銷符合,金流不符合——你就三四家、各自獨立、幾乎不互換。所以「各金流一條 flow 走到底」反而是正解,不是偷懶。
物流在你現在的規模就是一份存下來的資料 + 後台人工。它不參與金額分支、不參與跳轉,硬要跟金流做笛卡兒積是自找的。未來要自動化,也只是在某個狀態轉移點多一個 API side effect,到時候再加,現在不用預留。
所以真正會分岔的軸只有一個:付款方式。訂單送出 → 接著付款,就這樣。