平台将「开发一个业务模块」拆解为六类可配置元数据——数据模型、表单、列表查询、流程、权限、报表。使用者在设计器中拖拽编排，运行时由引擎解析渲染，全程无需编写前后端代码，也无需编译发版。
数据建模 在线定义字段、类型、校验与关联，自动生成物理表及 CRUD 接口
表单设计 拖拽布局、控件联动、显隐与校验规则，一份 Schema 前后端复用
列表查询 展示列、筛选条件、排序、批量操作、导出全部可配
流程编排 可视化审批流，条件分支、会签、节点表单权限、状态回写
权限体系 菜单 / 按钮 / 数据权限按角色分配，新建模块自动纳管
发布运维 配置版本化、diff、回滚，支持 dev → test → prod 导入迁移
平台采用元数据驱动的分层架构，将系统划分为设计层、元数据层、引擎层、运行层与数据层，并实现配置态与运行态的彻底分离。设计层以可视化方式产出数据模型、表单、流程与报表的标准化 Schema，元数据层负责版本管理、差异比对、跨环境迁移与模板继承，二者共同构成配置资产；引擎层在发布期将 Schema 编译为渲染快照，并驱动渲染、规则校验、流程流转与动态建表；运行层以统一 CRUD 网关配合权限拦截链、数据权限注入和二级缓存，为所有动态模块提供一致的执行环境；数据层则将配置元数据、业务数据与流程日志分域存储并做多租户隔离。该架构使研发工作从「逐模块编码」转为「建设解析与执行能力」，新增业务模块只需配置发布，无需改码发版；同时通过单一数据源保证前后端与数据库约束一致，通过预留扩展点覆盖复杂长尾场景，在交付效率与系统可控性之间取得平衡。
元模型的表达力边界：配置要覆盖 80% 常规场景，又不能为 20% 长尾把模型做成 DSL 地狱 → 分层 Schema（表单/列表/查询/权限/流程各自独立）+ 明确扩展点，先划清「配置止步于哪里」。
动态业务数据如何落库（最核心）：EAV 键值表灵活但查询慢、丢字段类型、难建索引；动态 DDL 建物理表性能好，但在线改表、删字段的数据安全、异构数据库兼容都难 → 常规场景自动建物理表并预留扩展列，元数据与物理列做映射登记，DDL 走版本化迁移脚本、禁止物理删列，只做逻辑下线与归档。
一处定义、三处一致：前端表单校验、后端参数校验、数据库约束容易各写一套，改配置后互相打架 → Schema 作为单一数据源，运行时统一生成 Validator、DTO 与建表约束，禁止在生成代码里手写校验。
运行时解析性能与集群一致：逐请求解析配置拖慢接口；多节点部署时改了配置，其他节点缓存不生效 → 配置编译成可执行「渲染快照」，本地缓存 + Redis 二级，发布时经消息总线广播版本号触发失效，节点按版本懒加载。
配置的版本、回滚与环境迁移：配置也是资产，要能 diff、回滚、跨环境导入，且绝不能冲掉线上已产生的业务数据 → 配置与业务数据分离存储，发布产物带版本号与依赖校验，流程走「预检 → 灰度 → 全量 → 回滚」，migration 只做增量不做事坏性变更。
动态权限注入：新建模块要自动纳入权限体系，数据权限（本部门/本人/自定义规则）要能挂到动态 SQL 上 → 菜单/按钮自动注册，数据权限抽象为规则表达式，在统一 CRUD 网关构建 SQL 阶段注入 WHERE 条件，避免每个模块各写一套。
流程与表单的事务一致性：审批状态回写跨服务易不一致，流程变量与动态字段类型不匹配 → 以「业务键 + 状态机」解耦，回调幂等 + 事务消息补偿，流程变量只取元数据登记的字段类型。
多租户
评论