把失控的 BPM 表單邏輯放回正確層級

情境

我接手 BPM 時，這套系統原本是為了快速滿足內部需求而建立的。

需求單純時這種做法很有效，但隨著表單種類、簽核流程與欄位行為持續增加，原本為了方便放在一起的邏輯開始互相牽制。

Ant Design Form 出現巢狀使用，submit 行為變得難以追蹤；工具列、留言區、歷史紀錄等框架層，也逐漸承接了原本應該屬於單一表單的商業邏輯。

驗證、欄位狀態與流程分支散落在不同 Component 之後，一個看似局部的修改，也很難確認真正的影響範圍。

我的判斷與做法

我認為真正的問題不是「共用元件做得不夠多」，而是：

同一件事情沒有明確的責任來源。

所以這次重構的核心不是繼續增加 abstraction，而是先把每種邏輯放回應該負責它的層級。

欄位狀態與驗證回到表單層自身管理；框架層只負責版面與流程控制，透過 Context 提供必要的控制點；可以重複使用的欄位與查詢／紀錄能力則整理成獨立模組，不讓它們反過來知道整個 BPM 的業務流程。

形成的結果

整理之後，不同 BPM 表單可以在一致的模型下運作。

新增或修改表單時，不需要再理解框架內散落的特殊邏輯，也降低了局部需求牽動整套流程的風險。

留下的思考

這次經驗讓我對 Single Source of Truth 有了更具體的理解：

SSOT 不一定代表所有東西都集中在同一個地方，而是每一條規則都應該只有一個真正負責它的位置。

當責任邊界清楚，抽象化才會讓系統更簡單；如果邊界本身就是錯的，再漂亮的共用層也只是在包裝耦合。