Q with AI:

多種金物流 流程的抽象化與設計 看完 實在覺得 好複雜好多抽象
其實 複雜的優惠邏輯 用 domain model 漂亮建立、測試 我喜歡

但 存進資料庫、呼叫副作用 這些 我覺好像不用太多抽象化
因為我還是要去實際跑一次、看資料庫、看 api 觸發狀況 才有安全感
那樣的話 金物流這部分 我感覺 各自一個 flow 走到底 可能還比較好看懂、好維護

我這看法 我的個性 你懂嗎?

甚至 我發現 好像不需要金物流排列組合

各種金流 各自 flow 就可以了

物流資訊只是存下來 後台人工處理

未來才需要把物流自動整合外部 那樣也只是 api side effect

主要訂單送出 還是接著付款 這樣而已

你有看法嗎?

AI answer:

懂,而且我覺得你這個直覺是對的,不是妥協。

你在區分兩種複雜度

  • 促銷邏輯是「本質複雜度」——規則多、會疊加、容易算錯,值得用 domain model 把它關進純函數裡,靠測試證明它對。這種地方抽象有回報。
  • 存 DB、call 金流 API是「接合複雜度」——它不難,只是雜、而且你必須親眼看它跑過一次才敢信。這種地方抽象只會把你想看的東西藏起來。

什麼時候抽象才划算

一句話:當你會在 runtime 真的多型切換、而且分支還會一直長時。促銷符合,金流不符合——你就三四家、各自獨立、幾乎不互換。所以「各金流一條 flow 走到底」反而是正解,不是偷懶。

金物流不用排列組合 —— 同意

物流在你現在的規模就是一份存下來的資料 + 後台人工。它不參與金額分支、不參與跳轉,硬要跟金流做笛卡兒積是自找的。未來要自動化,也只是在某個狀態轉移點多一個 API side effect,到時候再加,現在不用預留。

所以真正會分岔的軸只有一個:付款方式。訂單送出 → 接著付款,就這樣。


⭐️ Shopify 網站開發服務(給品牌)
https://job.turn.tw/shopify-services

⭐️ 小網站開發服務(功能明確、規模不大的需求)
https://job.turn.tw/small-website-services

⭐️ 台灣 Shopify 商家交流 LINE 群(非官方)
https://line.me/ti/g2/PZ_1LILWVWWuzZQ50HNpYA-A3k6QXWF6znqoBQ

⭐️ 台灣 Shopify 開發者 LINE 群(非官方)
https://line.me/ti/g2/YUasX5K3CJ4QdIx76zppjHlh3-q8w-xkSyK1LA

共有 0 則留言


⭐️ Shopify 網站開發服務(給品牌)
https://job.turn.tw/shopify-services

⭐️ 小網站開發服務(功能明確、規模不大的需求)
https://job.turn.tw/small-website-services

⭐️ 台灣 Shopify 商家交流 LINE 群(非官方)
https://line.me/ti/g2/PZ_1LILWVWWuzZQ50HNpYA-A3k6QXWF6znqoBQ

⭐️ 台灣 Shopify 開發者 LINE 群(非官方)
https://line.me/ti/g2/YUasX5K3CJ4QdIx76zppjHlh3-q8w-xkSyK1LA
🏆 本月排行榜
🥇
站長阿川
📝11   💬1   ❤️6
315
🥈
我愛JS
📝2   💬6   ❤️3
113
評分標準:發文×10 + 留言×3 + 獲讚×5 + 點讚×1 + 瀏覽數÷10
本數據每小時更新一次