如果可以把 ERP 重新做一次，很多舊問題似乎就有機會一起整理。不過，我會先想一件事：這些年累積下來的業務規則，我們真的都找齊了嗎？有些規則可能還留在程式裡，有些則是靠熟悉流程的人記得。

本篇名詞小筆記

• Strangler Fig Pattern：絞殺榕模式。對應到系統，就是新舊系統先並存，新系統從入口逐步接管功能與流量，最後才讓舊系統下線。
• Feature Flag：功能開關，不重新部署程式也能控制某項功能或導流規則是否啟用。
• Rollback：回退，發生異常時將服務或設定恢復到上一個可正常運作的版本。
• Compensating Transaction：補償，跨系統的寫入無法用一次 DB rollback 整筆撤銷，前一步已成功、後一步失敗時，要用反向動作把前一步抵銷，例如作廢剛建立的出貨單或沖回已扣的庫存。

今天要解決的問題

要估重建的時間與成本，得先知道要重建哪些東西。舊 ERP 比較讓人不放心的地方，就是有些規則平常不容易看見，可能要走到特定情境才會出現。因此，盤點能做到多完整，以及漏掉時怎麼處理，都會影響這個選擇。

我會從兩個時段來看風險。一次重建，要特別注意整體切換那一刻；漸進移轉，則要花比較長的時間注意新舊並存。哪個比較合適，還是要回到業務能停多久，以及團隊能承擔多少雙軌維護工作。

架構師視角：先建立入口，再決定移轉單位

圖 Day 04-1：漸進式現代化。

Strangler Fig 的想法，我覺得可以先理解成：把入口整理好，再一項一項把功能導到新服務。還沒移轉的繼續由 ERP 處理，完成驗證的再切過去，每次都清楚知道誰在負責。

入口整理好，才有地方控制哪些功能走新服務。如果還是每個呼叫端各自改接，切換時就得逐一協調，所以這一步會先安排。

至於一次要移多少，我會先看這一段能不能自己驗證、自己回退。完整的業務流程比較容易說明完成了什麼，也比較容易請使用單位一起確認，所以我會從完整的業務流程來挑。

唯讀功能的範圍比較容易掌握，也適合先拿來演練流量切換、監控與回退：切一部分呼叫過去、看數字有沒有變差、必要時切回舊路徑。所以第一條流程，我會先考慮物料查詢這類唯讀功能。等這些基本工作走順了，再接著評估有寫入與補償需求的交易。

圖裡也保留了 Anti-Corruption Layer，也就是後面幾篇說的 ERP Adapter，讓 ERP 的模型與協定在這一層轉換。新服務用自己的契約處理資料，Day 13、Day 14 再把這份責任說明得更仔細。

工程師視角：導流規則、契約比較與寫入路徑

後面每次切換，都要有依據。所以真正開始接之前，我會先準備三件事：導流規則的版本、新舊回應的比較方式，以及唯一的寫入路徑。

有些差異原本就允許，例如時間戳記、排序與預設值；範圍沒訂清楚，比對時就會把時間都花在這些地方。所以比較新舊回應前，我會先列出哪些欄位要完全一致，哪些可以不同。

寫入路徑要維持單一來源。所謂雙寫，是同一筆資料同時寫進新服務與 ERP 兩邊。若確實需要雙寫，必須補上主資料來源定義、失敗補償與對帳機制，並明確說明兩邊不一致時以哪一邊為準。這一點在 Day 08 的資料所有權會再展開。

每次切換也要設定 feature flag、觀察期與 rollback 條件。導流比例要能即時調整，並記錄每次調整的時間與操作者；異常發生時才能對應到某一次導流變更，而不是只能從時間上猜測。

策略取捨與限制

一步一步移轉，確實比較容易控制每次變更，但兩套系統都要維護的時間也會拉長。所以，每移一項，我都會順便記下舊介面何時可以停用，以及還有哪些依賴要先處理。

驗證方式與衡量指標

第一條流程就開始收集這些資料，後面才有比較基準。如果契約差異或對帳結果還拿不到，就先把比較機制補好，再繼續擴大導流。

今天先整理到這裡

今天比較完兩種方式，我認為最重要的準備是：每一步都能驗證，也知道怎麼回退。下一篇，接著看看微服務、模組化單體與混合架構，各自適合什麼條件。

參考資料

1. Microsoft Azure Architecture Center, Strangler Fig pattern，查閱日期：2026-09-17。
2. Microsoft Azure Architecture Center, Anti-Corruption Layer pattern，查閱日期：2026-09-17。