以 FormDefine 作為「表單結構描述模型」,統一驅動資料、介面與邏輯

在 BeeNET 架構中,FormDefine 是一份跨層共用的結構描述模型,用來定義:
其目的不只是描述表單,而是作為整個系統的定義中樞(Definition Hub),讓 UI、資料庫、邏輯由同一份定義衍生,確保一致性並降低重複開發成本。
核心精神:
FormDefine 是整個 BeeNET 架構的源頭,其他產物皆由此推導。
| 元件 | 性質 | 來源 | 用途 |
|---|---|---|---|
| FormDefine | 表單結構描述模型 | 人工/AI/工具建立 | 系統核心定義層 |
| FormLayout | UI 配置模型 | 從 FormDefine 推導 | 產生前端介面 |
| DbTable | 資料表結構 | 從 FormDefine 推導 | 建立/同步資料庫 |

💡 FormDefine = 系統的跨層共享定義模型
不僅統一定義,也提供每一層各自最佳化的彈性。
開發深度依需求複雜度而調整,但所有模式皆基於同一份定義運作。
| 模式 | 自由度 | 實作方式 | 適用情境 |
|---|---|---|---|
| NoCode | 中 | 定義生成 UI + DB | 標準流程、資料導向 |
| Low Code | 高 | 事件、條件、規則擴充 | 輕度客製邏輯 |
| Any Code | 完全 | 自訂 UI / BusinessObject / Repository | 複雜邏輯 / 跨模組整合 |
設計理念:
- NoCode:最快速產生功能
- LowCode:以事件 / 規則補上差異
- AnyCode:保留完整程式自主權(Full Control)
→ 不會被框架限制,高度客製仍可掌控
這三種模式是同一條演進軸線上的不同深度,而非互斥的技術堆疊。
BeeNET 架構具備自我進化特性:

💡 每一次客製都能成為下一次的自動化能力。
ERP 的核心圍繞在 表單資料模型(Form / Master / Detail),但傳統做法往往造成大量重複工作與維護成本。以下整理出實務上最常見的瓶頸。
當業務需要「新增一個欄位」時,工程師必須同時調整三個地方:
這代表:
→ 同一份規格在三層重複實作,極易產生不一致。
不同模組由不同工程師負責,常見現象包括:
系統越累積越難以維護。
許多 ERP 專案的客製功能:
最終都會形成 難以治理的技術債。
| 觀點 | 傳統 ERP 開發 | 定義導向 |
|---|---|---|
| 欄位新增 | UI / API / DB 各改一次 | 一處修改,自動同步 |
| UI 生成 | 人工維護、容易不一致 | 自動推導、可調整 |
| 規則一致性 | 分散於前後端各自實作 | 集中於定義層,由系統保證一致 |
| 客製化 | 重工、難複用、專案越做越亂 | 以事件 / 規則擴充,可回饋架構 |
| 系統演進 | 重構風險高、擾動大 | 以定義為中心,演進更安全 |
定義導向的價值在於:
最終,系統開發將從「撰寫程式碼」進化為:
✨ 建構模型 → 定義行為 → 推動架構演進
這讓 ERP 具備更高的一致性、可理解性與長期可維護性。
想了解本篇提到的 FormDefine 與 DbTable 在實際系統中的運用,可參考以下兩篇文章:
📘 HackMD 原文筆記:
👉 https://hackmd.io/@jeff377/definition-driven-erp
📢 歡迎轉載,請註明出處
📬 歡迎追蹤我的技術筆記與實戰經驗分享
Facebook | HackMD | GitHub | NuGet