DSL 能力矩阵 —— AuraBoot 的武器库
业务系统真正难的从来不是「能不能做」,而是做完之后改不动、各处都要自己扛:状态机写死在 service、权限判断散在 controller、字段联动埋在前端事件里、接 AI 还要再包一层 API。
AuraBoot 的答案是一套 DSL(声明式领域语言):业务的「是什么」用版本化 JSON 描述,「怎么执行」由运行时统一兜底。页面、字段、命令、权限、联动、图表——全是数据,不是手写代码。这一页把这套 DSL 的全部能力一屏铺开,每一层都告诉你它消掉了哪个痛点,以及去哪读细节。
想先看这套能力怎么拼成一个真实业务模块 → 读 CRM 模块解剖 ★,再回来看全景。 想理解引擎为什么这样设计(契约失败即报 / 可升级 / AI 可读)→ 读 DSL 引擎原理。
📐 本页所有数字均来自 live 源码:
DslRegistry.java(平台能力注册表,25 个封闭枚举)、ComponentRuntimeManifest.ts(Smart 组件)、ActionRegistry.ts/LinkageEngine.ts(交互)。不是营销话术,每个标识符都能 grep 到。
一句话大图
一个有 1000 个页面的平台,不是 1000 种页面架构;是一种架构,被实例化 1000 次。
所有业务模块都是同一个形状——模型 → 命令 → 权限 → 页面,全用 DSL 声明、走同一条命令管道。换个领域(CRM / 采购 / 质量 / 生产)只是换一组声明,运行时不变。下面这张矩阵,就是「这一种架构」能表达的全部维度。
一条真实业务线怎么串起来
不要把 DSL 理解成一堆分散配置。以 workflow-demo 的请假审批为例,同一条业务线从数据、按钮、权限、流程到 AI 工具边界都是同一组声明在驱动:
| 层 | 真实对象 | 作用 |
|---|---|---|
| Model | wd_leave_request / wd_leave_balance | 申请记录与年假余额,字段如 wd_req_type、wd_req_days、wd_req_status、wd_req_process_instance |
| Command | wd:create_leave_request、wd:create_and_submit_leave_request、wd:submit_leave_request | 创建草稿、创建并提交、草稿提交;所有写入都走命令管道 |
| Permission | wd.leave_request.manage / wd.leave_request.submit | 页面按钮与命令执行共用同一组权限码 |
| Page | wd_leave_request_list / wd_leave_request_form / wd_leave_request_detail | 列表、表单、详情页引用同一模型字段与命令码 |
| Rule | wd_leave_validation / wd_leave_routing | 提交前校验余额与附件;流程内按 days 输出 approverRole |
| BPM | wd_leave_approval | rule-task → exclusiveGateway → 主管/HR userTask → 记录回写 → 通知 |
| SLA | wd_manager_approve_sla / wd_hr_approve_sla | 挂在人工审批节点上,生成 running / overdue 的 SLA record |
| AI 边界 | agent_hint + cmd_risk_level: "L2" | 同一条命令可以暴露给 UI、自动化、BPM 节点或 AI 工具,但风险分级与权限仍由命令治理 |
这条链路没有第二套“页面专用状态机”或“AI 专用 API”。页面只是调用 command,command 先跑 preActions 规则,成功后由 postActions 启动 BPM,人工任务由统一 Task Center 处理,SLA 由节点配置激活。想看完整操作和截图,读 BPM 端到端示例。
能力矩阵
每一层 = 一个常规做法的痛点 + DSL 的解法 + 能力规模 + 深读入口。
1. 页面类型 —— 不为每种页面手写布局
痛点:列表、表单、详情、看板,常规做法每一种都手写一套组件 + 路由。
解法:声明 kind,渲染器按 kind 装配。5 种 page kind覆盖绝大多数业务 UI:
| kind | 用途 |
|---|---|
list | 分页列表(filter / toolbar / 行操作 / 保存视图) |
form | 创建或编辑单条记录,可向导式 |
detail | 以读为主的记录视图(header / tabs / 子表 / 时间线) |
dashboard | 图表、KPI、绑定 widget 的网格 |
composite | 混合 kind 的多区域复合布局 |
→ Page 与布局
2. Block 体系 —— UI 拼装不再散落在代码里
痛点:每个页面的区块(表单段、表格、工具栏、图表、子表)都是手写 JSX,改一处动一屏。
解法:页面由 35 种 block 递归组合而成,每种 block 由 BlockRegistry 注册、kindPolicy 约束「能出现在哪」。未知 block 类型直接抛错,绝不静默空渲染。
| 分类 | 代表 block |
|---|---|
| 表单输入 | form · form-section · form-buttons · form-wizard |
| 数据展示 | table · sub-table · description · detail-section · embedded-list · card-grid |
| 容器布局 | tabs · divider · monthly-grid |
| 动作与筛选 | toolbar · filters · workbench-action-bar |
| 图表与指标 | chart · stat-card · metric-strip |
| 工作台 / 协作 | status-banner · evidence-panel · review-drawer · record-inspector · candidate-list · activity-timeline · record-comments · field-history · bpm-panel |
| 专项 / 逃生 | trace-graph · gerber-viewer · selection-info · rich-text · ai-fill-banner · custom |
3. 字段类型与 Smart 组件 —— 每个字段不再手配控件
痛点:手写表单,每个字段都要选控件 + 配校验 + 接字典 + 做脱敏 + 处理 reference 联想;改一次模型,前端跟着改。
解法:13 种数据类型声明数据语义,运行时自动映射到 50 个 Smart 组件(40 个通用 + 10 个模块自注册),并按字典/特性自动推断控件。
| 维度 | 规模 |
|---|---|
| 数据类型 | 13(string / text / integer / decimal / boolean / date / datetime / json / enum / reference / computed / ai_text / money) |
| Smart 组件 | 50(表单 / 选择器 / 日期 / 展示 / 交互 / 布局,注册表开放可扩展) |
| 虚拟字段 | 3 种(只读计算 / 物化 / 临时)+ Roll-Up 汇总 + JSONB 虚拟字段 |
| 字段特性 | required / readonly / searchable / unique / indexed / mask 等整套 feature |
→ 深读:字段类型与 Smart 组件 ★
4. 命令执行引擎 —— 横切关注点由管道统一兜底
痛点:鉴权、校验、事务、审计、发事件,常规做法每个业务里都要自己补一遍。
解法:所有写入都是一条命令,走同一条 20 阶段管道。两种执行模式:ExecutionConfig(纯 JSON 声明,覆盖约 80% 常规 CRUD + 状态机)与 BindingRule(绑注册 handler,做跨系统编排)。
| 维度 | 规模 |
|---|---|
| 命令类型 | 8(create / update / delete / state_transition / query / batch / custom / action) |
| Precondition 操作符 | 16 |
| autoSet 策略 | 14(current_user / current_date / sequence / expression …) |
| 风险分级 | 5(L0 安全读 → L4 不可逆),供 AI 调用分级 |
5. 交互与联动 —— 低代码真正的墙
痛点:CRUD 不难,难的是联动:省/市级联、字段按另一字段显隐、按钮按记录状态变灰、一个动作触发一串后续。手写时这些逻辑散落在前端事件里,改规则要翻组件。
解法:三套声明式机制覆盖全部交互——条件表达式(visibleWhen / disableWhen + 72 个 fn.* 业务函数)、LinkageEngine 8 种联动(含多级级联)、Action 三层架构(约 30 个原子 action + 多步 flow 编排)。
| 机制 | 规模 |
|---|---|
| 条件表达式 | visibleWhen / disableWhen,上下文 row. / record. / form. |
业务函数 fn.* | 72(逻辑 7 / 文本 16 / 数值 13 / 日期 14 / 类型 10 / 集合 12) |
| 联动 action | 8(show / hide / enable / disable / setRequired / setValue / setOptions / validate) |
| 按钮 action | 5 形态(command / navigate / builtin / flow-steps / flow-handler)+ 约 30 原子 action |
→ 深读:DSL 交互与联动 ★
6. 数据源 —— 页面不写死 SQL/URL
痛点:页面里写死 SQL 或 API URL,改一处 SQL 要动每个页面;没权限钩子。
解法:4 种逐步增强的数据源,任何非平凡场景优先命名查询(服务端存储、按 code 绑定、可挂权限)。
| 模式 | 何时用 |
|---|---|
static | 小枚举硬编码选项 |
| 模型绑定 | 单一模型列表/详情(直接写 model code) |
namedQuery | 服务端预定义、带参、可复用查询 |
api | 参数化 API,常依赖其它字段(dependsOn 联动) |
7. 列表与查询 —— 筛选/汇总不再每页重写
痛点:列表的筛选、聚合、行内编辑、个人视图,常规做法每张表重做一遍。
解法:列表能力全部声明化:16 种查询操作符、列级聚合(SUM/COUNT/AVG/MAX/MIN)、行内编辑、状态分页签(list-tabs)、6 种 SavedView(table / kanban / calendar / gallery / gantt / tree)× 3 种范围(个人/团队/全局)。
→ DSL 引擎 · 字段渲染与校验(列表与查询深讲规划中)
8. 校验闸门 —— 配置错当场报,不变成「UI 有点怪」的工单
痛点:配置写错了静默 fallback,变成三个迭代后才有人提的工单。
解法:两道闸门——静态审计(pre-commit 可跑)+ 平台 import validator(真闸门)。错误以 S-* 码当场暴露:
S-PAGE-LABEL(缺 label)· S-PAGE-FORM-REQUIRED(required 未镜像)· S-PAGE-TABLE-DICT(字典 code 不存在)· S-PAGE-BUTTONS(空按钮区)· S-EXT-HANDLER(binding rule 指向未注册 handler)。
9. Designer 家族 —— 不是各自为政的低代码孤岛
痛点:低代码平台常是一堆互不相通的设计器,产出彼此孤立。
解法:6 个 OSS Designer 共享同一套元数据形态(palette / 画布 / 属性面板 / 保存发布),产出的都是可被 runtime 渲染、可被治理校验、可入 Git 评审的结构化元数据。
Page Designer · Dashboard Designer · BPMN Designer · Flow Designer · Query Builder · Report Designer
10. AI 原生 —— 命令天生就是 AI 工具
痛点:给系统接 AI,常规做法是事后再包一层 API,还要重新定义权限和风险边界。
解法:每条命令自带 cmd_risk_level(L0–L4)+ agent_hint,同一条命令同时服务 UI 按钮 / 自动化 / BPM 节点 / AI agent。AI 读 schema 跟读一行数据库记录一样——schema 本身就是意图。
→ AI 总览 · MCP 与 Tool
11. 企业版叠加扩展 —— 同一契约,向上叠加
社区版契约(page / block / field / command / ExecutionConfig / 简单 BindingRule)已覆盖多数场景。商业版沿同一份契约叠加更丰富的 binding 表达式、跨模型联查数据源、跨页跨字段校验、设计器协作编辑——社区版页面在商业版里一字不差地继续渲染。
怎么读这份矩阵
- 只想快速理解平台 → CRM 模块解剖 一篇足够,看「一种形状」怎么落地。
- 想吃透交互这块硬骨头 → DSL 交互与联动。
- 要把字段/组件用全 → 字段类型与 Smart 组件。
- 想看全部业务模块 → 业务场景目录。
- 想懂引擎设计取向 → DSL 引擎原理。