ERP 的複雜度不在單一功能有多難，而在同一件事被重述太多次、乘以太多張表、再乘以太多次客製。
2026 iThome 鐵人賽連載，共 30 篇，2026-08-17 至 2026-09-15。全系列已完結。
這個系列談的不是怎麼用框架做一張表單，而是怎麼設計一套能驅動上百張表單的框架：唯一真相放在定義而非程式碼，資料庫結構、SQL、多前端畫面、驗證與計算、多語系、多租戶與客製化都從同一層定義衍生。案例用 Northwind 驗證，但案例是佐證，不是主角。
談機制與取捨，不寫使用教學；每個設計的代價會跟它的好處寫得一樣清楚。
問題是什麼、典範的分歧點在哪裡，以及案例登場。同一個欄位在兩種典範下各要改幾處，這一章給出對照。
定義檔有哪幾種、各自的生命週期為什麼不同，以及一份結構描述怎麼長出資料庫結構、CRUD SQL、多前端畫面與業務規則。
不寫 DTO 的話，資料怎麼跨層傳；多資料庫的共同行為只有哪兩件；一份快取怎麼知道它的來源已經變了。
定義表達不了的那一段由誰接手、擴充點開在哪裡，以及一次呼叫從呼叫端走到業務物件經過了什麼。
同一套程式怎麼讓每一家公司長得不一樣，而且不必開分支、不必重新編譯部署。客製化這條線目前停在哪裡，也說清楚。
資料送出去的時候長什麼樣、經過哪幾道保護、誰有資格呼叫，以及事後查得到什麼。
金額、數量、日期與時刻，這些值的語意怎麼從定義一路保到資料庫，中間不被任何一層悄悄改掉。
拿 Northwind 那套應用逐項檢視：定義、框架與應用程式碼各負責哪一段。最後給一張全圖，以及這套設計不適合什麼系統。
系列裡談的機制都做在一套開源框架上：bee-library。案例是另一個 repo，bee-northwind-avalonia，框架以套件引用進來，裡面只有應用自己的定義檔與程式。
框架在這個系列裡只有一個角色：證明這些想法不是紙上談兵。你完全可以不用它，只把「讓定義當源頭」這個想法帶走，用你熟悉的語言和工具去實現。
本系列同步發表於 HackMD，完整目錄
jeff377
iThome鐵人賽
看影片追技術