ERP 的复杂度不在单一功能有多难，而在同一件事被重述太多次、乘以太多张表、再乘以太多次定制。
2026 iThome 铁人赛连载，共 30 篇，2026-08-17 至 2026-09-15。全系列已完结。 博客园版每天转载一篇，已转载的篇名可直接点开；繁体原文全系列见 HackMD。
这个系列谈的不是怎么用框架做一张表单，而是怎么设计一套能驱动上百张表单的框架：唯一真相放在定义而非代码，数据库结构、SQL、多前端界面、验证与计算、多语言、多租户与定制化都从同一层定义衍生。案例用 Northwind 验证，但案例是佐证，不是主角。
谈机制与取舍，不写使用教学；每个设计的代价会跟它的好处写得一样清楚。
第一章 · 定义驱动的起点（Day 1–3）
问题是什么、范式的分歧点在哪里，以及案例登场。同一个字段在两种范式下各要改几处，这一章给出对照。
- Day 1 · 为什么 ERP 需要 Definition-Driven 框架
- Day 2 · Definition-Driven 架构总览
- Day 3 · Northwind 案例的八张表单与自定义业务对象
第二章 · 定义层设计（Day 4–8）
定义文件有哪几种、各自的生命周期为什么不同，以及一份结构描述怎么长出数据库结构、CRUD SQL、多前端界面与业务规则。
- Day 4 · 定义文件的用途与分类
- Day 5 · FormSchema 如何驱动 SQL
- Day 6 · TableSchema 与数据库结构升级
- Day 7 · FormLayout 与多前端界面生成
- Day 8 · 声明式业务规则与计算列
第三章 · 数据访问与缓存（Day 9–12）
不写 DTO 的话，数据怎么跨层传；多数据库的共同行为只有哪两件；一份缓存怎么知道它的来源已经变了。
- Day 9 · 数据与定义分家，表单不必各自建类型
- Day 10 · 多数据库支持：CRUD 与结构升级
- Day 11 · 数据访问层的连接、Transaction 与查询条件
- Day 12 · 定义与数据缓存的跨节点失效
第四章 · 业务逻辑与 API（Day 13–18）
定义表达不了的那一段由谁接手、扩展点开在哪里，以及一次调用从调用端走到业务对象经过了什么。
- Day 13 · Session 管理与生命周期
- Day 14 · 业务对象的扩展点与重写时机
- Day 15 · API 契约分层与类型注册表
- Day 16 · JSON-RPC 2.0：协议选型与请求管道
- Day 17 · Connector 与调用端的职责收敛
- Day 18 · 错误契约与用户可见消息
第五章 · 多租户与定制化（Day 19–21）
同一套程序怎么让每一家公司长得不一样，而且不必开分支、不必重新编译部署。定制化这条线目前停在哪里，也说清楚。
- Day 19 · 定制层的范围与叠加粒度
- Day 20 · 多语言定制与资源结构
- Day 21 · 业务逻辑定制与 Plugin 的四个时点
第六章 · 传输、安全与审计（Day 22–25）
数据送出去的时候长什么样、经过哪几道保护、谁有资格调用，以及事后查得到什么。
- Day 22 · XML、JSON 与 MessagePack 的分工
- Day 23 · API Payload 安全管道：顺序、保护等级与密钥
- Day 24 · 权限的三轴：动作、行与列
- Day 25 · 审计轨迹与变更的前后值
第七章 · 数据语义正确性（Day 26–28）
金额、数量、日期与时刻，这些值的语义怎么从定义一路保到数据库，中间不被任何一层悄悄改掉。
- Day 26 · 数值语义、多币种与计量单位
- Day 27 · Date、DateTime 与 Time 的语义分界
- Day 28 · DateTime 的时区转换
第八章 · 案例回访与全图（Day 29–30）
拿 Northwind 那套应用逐项查看：定义、框架与应用代码各负责哪一段。最后给一张全图，以及这套设计不适合什么系统。
- Day 29 · 定义、框架与应用代码各负责哪一段
- Day 30 · 三段开发深度与框架全图
关于这个系列的框架
系列里谈的机制都做在一套开源框架上：bee-library。案例是另一个 repo，bee-northwind-avalonia，框架以包引用进来，里面只有应用自己的定义文件与程序。
更新：系列当时用的 Bee.NET（bee-library）已由 Polhem 接手，机制沿用，框架做了大幅重构，以 MIT 授权开源。bee-library 与 bee-northwind-avalonia 两个 repo 已封存，文中的类型名与代码以写作当时的 bee-library 为准。
框架在这个系列里只有一个角色：证明这些想法不是纸上谈兵。你完全可以不用它，只把「让定义当源头」这个想法带走，用你熟悉的语言和工具去实现。
文章摘自：https://www.cnblogs.com/jeff-tsai/p/23459221/ironman-2026
京ICP备14020293号-4