模型驱动架构（MDA）在低代码中的落地：表单、视图与逻辑的元数据化
结论先行：模型驱动架构（MDA, Model-Driven Architecture）是对象管理组织（OMG）在 2001 年发布的架构思想，核心主张是模型与实现分离——先用平台无关的模型描述业务，再自动转换成具体平台的实现。低代码平台就是这套思想 20 年后最成功的工程化落地：把表单、视图、逻辑全部描述成元数据（Metadata），运行时由引擎解释执行或编译为代码。理解 MDA，等于拿到了看懂任何低代码平台源码的地图。
很多开发者第一次接触低代码时会觉得"拖拽出页面"很神奇，其实背后没有任何魔法：你拖的每一下都在编辑一份模型，真正干活的是模型驱动的转换与执行引擎。
一、MDA 的本来面目：PIM 与 PSM 的分离
OMG 的规范里定义了三层模型：计算无关模型（CIM）描述业务本身、平台无关模型（PIM, Platform Independent Model）描述"要做什么"、平台相关模型（PSM, Platform Specific Model）描述"在某个技术栈上怎么做"。MDA 的承诺是：维护好 PIM，各技术栈的 PSM 自动生成。
低代码怎么对应这套概念：编辑器里画出来的页面结构、数据模型、流程定义，本质上就是 PIM；编译或渲染到微信小程序、H5、原生 App 上的产物，就是 PSM。平台提供的"多端发布"能力，就是从同一份 PIM 到多个 PSM 的自动转换。这也是为什么成熟的低代码平台都强调"一套 DSL（Domain Specific Language，领域特定语言）多端运行"——没有模型与实现分离，多端就只能靠复制粘贴。
二、表单的元数据化：字段定义驱动存储与校验
是什么：在低代码平台里，一张表单不是一段 HTML，而是一份字段元数据：字段名、字段类型、校验规则、默认值、联动规则、权限标注。存储层的物理表结构由这份元数据推导生成，前后端校验也共用同一份定义。
为什么这样设计：表单是业务系统变化最频繁的部分。如果字段类型只存在于数据库建表语句里、校验规则只存在于前端代码里，改一个字段要动三四处；元数据化之后改一处，存储、接口、校验、界面全部同步。这也是模型驱动最直接的收益：单一事实来源（Single Source of Truth）。
权衡取舍：元数据能表达的字段类型是有限的。日期区间、附件、级联选择这类通用类型可以内置，但"动态子表 + 逐行校验 + 跨表引用"这类复杂结构，对元数据模型的建模能力是真正的考验，也是各家平台拉开差距的地方。
三、视图的元数据化：页面结构即组件树
是什么：视图层的元数据通常是一棵组件树：每个节点记录组件类型、属性值、样式配置、事件绑定和对数据模型的引用。渲染器加载这棵树，递归实例化为真实组件。
为什么这样设计：视图引用模型而不是复制模型，是保证一致性的关键——模型里把"手机号"字段改个名字，所有引用它的视图自动更新。同时，因为视图是纯数据，它天然可以被序列化存储、做版本 diff、在预览环境与生产环境之间搬运。
权衡取舍：组件树的表达力取决于物料协议的丰富度。属性、事件、插槽三类描述缺一不可，缺了插槽描述，"往容器组件里塞任意子组件"这类场景就表达不了，平台就只能靠硬编码特判。
四、逻辑的元数据化：从事件到流程节点
是什么：业务逻辑的元数据化有两个层次：轻量的部分用表达式（比如按钮禁用条件、字段联动公式），复杂的部分用流程编排——把"条件分支、循环、调用接口、赋值、发送通知"组织成节点图，由流程引擎解释执行。
为什么这样设计：把逻辑也变成数据后，逻辑第一次可以被可视化展示、被非开发人员理解、被平台统一监控。表达式引擎负责点状逻辑，流程引擎负责链状逻辑，两者配合覆盖大部分业务场景。
权衡取舍：逻辑元数据的表达力天花板比代码低得多。递归、复杂数据变换、异常恢复这类场景，元数据描述起来要么极其别扭要么根本表达不了，平台必须预留写代码的出口（详见延伸阅读中表达式引擎与逃生舱的文章）。
五、权衡取舍：元数据化的边界在哪里
收益清单：①一致性——存储、接口、校验、视图共享一份模型；②多端——一份模型转换到多个 PSM；③治理——模型可版本化、可 diff、可审计；④效率——高频变更落在元数据上，发布链路短。
代价清单：①抽象泄漏——超出模型表达力的需求会把元数据层搅得越来越复杂；②调试困难——运行报错的栈是引擎栈，与业务模型之间隔着一层转换，定位问题要靠平台自带的调试工具；③性能开销——解释执行比原生代码慢，依赖引擎优化；④学习成本——团队要学一套模型语言，这套语言只在平台内有效。
一句话总结：元数据化适合"变化频繁、模式重复"的 80% 场景，剩下 20% 需要诚实地交给代码，模型驱动的成熟度恰恰体现在这 20% 的处理设计上，具体怎么开口子，低代码逃生舱设计给了四类标准舱口。
FAQs
Q1：模型驱动架构（MDA）和数据驱动是一回事吗？
A：不是。MDA 强调用模型描述整个应用（数据、界面、逻辑）并自动转换为实现；数据驱动只强调 UI 随数据状态变化渲染。低代码平台通常两者兼有：MDA 在平台层，数据驱动在渲染器层。
Q2：元数据化之后数据库还能直接用吗？
A：能。元数据最终会推导成真实的物理表和接口，数据库层面就是普通的表。但直接改库结构会造成元数据与物理结构不一致，正确做法是回到建模工具里改，让平台同步两边的结构。
Q3：为什么有的平台感觉"限制了自由度"？
A：这正是模型驱动的边界。平台把可表达空间约束在元数据模型内，换取一致性与治理能力。当你频繁感到受限，说明需求进入了 20% 的代码区，应该走平台提供的自定义出口而不是绕过模型。
延伸阅读
- 低代码平台架构对比——看不同平台如何组织模型与引擎的关系
- 低代码 DSL 怎么设计？从 JSON Schema 到页面渲染——视图元数据化的协议设计细节
- 低代码表达式引擎原理：数据绑定与联动计算——逻辑元数据化的执行核心