夜雨聆风从 ObjectStack、ObjectQL 到多数据库 Runtime，看企业应用为什么正在重新定义数据的真理之源？
适合阅读：后端 / 架构师 / CTO / DBA / SaaS 创业者 / AI 应用开发者
先问一个每个后端都答得上来、但很少认真想的问题:
Customer（客户），到底是什么？
在一个传统 CRM 里,你的第一反应大概是——它是一张表:
CREATE TABLE customers ( id, name, industry, owner_id, status, ... ); |
然后整个系统,就围着这张表转起来了:ORM 的 Model 映射它、API 暴露它、前端表单编辑它、列表展示它、权限控制它、报表统计它、工作流驱动它。这张 customers 表,俨然成了客户这个概念在系统里的化身。
但现在,问一个第一性的问题:如果有一天,你把底层数据库从 MySQL 换成了 PostgreSQL、甚至换成 MongoDB, Customer 这个业务概念,会跟着消失吗?
当然不会。客户还是那个客户——有名字、有行业、有负责人、有状态、有联系人、有商机。变的只是它存在哪儿、怎么存。
Customer 是一个业务概念,而 customer 这张表,只是 Customer 的一种存储实现。
可如果是这样,一个问题就冒出来了:既然客户这个业务概念,并不等于那张表,那为什么几十年来,企业软件的架构,一直让表 / Schema占据了那么核心、那么高的位置?
一、Database First 是怎么形成的？
先给传统架构一个公道话。几十年来,企业软件的标准骨架是这样的,而且它无比成功:
Database（数据库） ↓ ORM ↓ Backend（后端） ↓ API ↓ Frontend（前端） |
这种数据库优先的设计,有极强的工程合理性:数据一致性、事务、查询性能、索引、可靠性、成熟的生态……几十年积累下来,数据库这一层坚如磐石。Database First 绝不是错误,它是过去几十年互联网和企业软件的最佳实践之一。
但问题,出在应用变复杂之后。随着系统越做越大,数据库的 Schema,开始悄悄地、越来越多地,承担起了业务模型的职责。一堆数据库实体——
customer table （客户表） opportunity table（机会表） approval table （审批表） activity table （活动表） |
——它们不再只是数据怎么存的问题,而是开始直接决定 API 长什么样、UI 怎么展示、工作流怎么流转、权限怎么设、报表怎么出。于是一件事悄悄发生了:
业务模型,和存储模型,耦合在了一起。你的业务是什么,被你的数据怎么存绑架了。改一个业务概念,你得先动数据库;而数据库的结构,又反过来限制了业务能怎么变。
二、一个 Customer，为什么不该等于一张表？
我们说Customer是一个业务对象。它拥有一系列属性和关系:名称、行业、负责人、状态、联系人、商机、活动记录。这些,是客户这个业务概念的内涵。
但关键在于:这些业务属性,不需要、也不应该,直接等价于数据库的 Schema。同一个 Customer,它完全可以存储在 PostgreSQL 里,也可以存在 MySQL、MongoDB、SQLite,或者别的存储后端里。业务概念不变,存储实现可以千变万化。
业务对象（Business Object） ≠ 数据库表（Database Table）
这个不等于,就是 Business Object First 的地基。它把一件长期被混为一谈的事,重新分开了:客户是什么是一个业务问题,客户怎么存是一个存储问题。前者应该是稳定的、上层的;后者应该是可替换的、下层的。
三、ObjectQL 到底解决什么问题？
以下涉及仓库的描述,以其当前公开源码 / 文档为准。
先纠正一下:ObjectQL 不是一个 SQL 的替代品。如果只把它看成换一种语法查数据,就完全没抓住重点。更准确的问法是——
ObjectQL，在业务对象和底层存储之间，增加了一层什么样的抽象？
根据当前仓库,ObjectQL 围绕业务对象提供了一套统一的操作能力:对象(Object)、字段、关系、过滤、排序、聚合、查询、增删改查等,都是基于业务元数据来表达的。它建立起这样一条链路:
Application（应用） ↓ ObjectQL（面向业务对象的查询层） ↓ Driver（存储驱动） ↓ Database（具体数据库） |
这层抽象的关键在于:上层业务面对的是对象(Customer、Opportunity),它说的是找出这个客户名下所有金额大于 100 万的机会;而用什么 SQL、怎么 join、走哪个索引这些具体存储的事,被压到了 Driver 这一层。业务代码里,不再散落着对某个具体数据库的假设。
于是,数据库之间的差异,被压缩、封装在了 Runtime / Driver 这一层,而不是像过去那样,扩散、渗透到整个应用的每一个角落。
举个示意（具体语法以仓库为准）
为了让你有直观感受,我用示意的方式对比一下。传统你可能这样查:
-- 传统 SQL：你得知道表名、字段名、join 怎么写 SELECT * FROM crm_opportunity o JOIN crm_customer c ON o.customer_id = c.id WHERE o.stage = 'proposal' AND o.amount > 1000000; |
而面向业务对象的查询,表达的是业务意图,大意是这样
// 面向业务对象（示意，非确切语法） query("Opportunity") .where({ stage: "Proposal", amount: { gt: 1000000 } }) .with("customer") // 你说的是「阶段为 Proposal、金额大于 100 万的机会」， // 而不是「哪张表、哪个外键、哪种 join」。 |
(说明:以上为帮助理解的示意代码,ObjectQL 的确切 API 与语法,请以当前仓库源码为准。)
四、多数据库支持，真正的价值不是兼容更多数据库
这是一个重要的反常识观点。
很多人一看到支持 PostgreSQL / MySQL / SQLite / MongoDB,第一反应是:哦,兼容性不错嘛。——但这其实抓错了重点。
真正值得问的,不是它能连多少种数据库,而是:业务模型,是否因此摆脱了对某一个具体数据库的直接依赖?
看这两种结构的区别。传统上,业务逻辑里其实渗透着对具体数据库的假设(SQL 方言、ORM 的行为、某种特性):
传统： Business Logic（业务逻辑） ↓ （渗透着 SQL / ORM 的种种假设） Database |
而在业务对象优先的结构里,业务逻辑只面对业务对象,存储被隔离在下面:
业务对象优先： Business Logic（业务逻辑） ↓ Business Object / ObjectQL ↓ Storage Driver（存储驱动） ↓ Database |
所以,支持多数据库只是表象,真正的价值是——业务语义与存储实现,彻底解耦了。能换数据库只是这个解耦顺带的结果,而不是目的本身。
五、为什么 AI Agent，更需要 Business Object First？
一个 AI Agent,如果要操作企业数据,它最好面对的是什么?我们对比一下。它不应该主要去理解这种东西:
SELECT * FROM crm_opportunity WHERE stage = 'proposal'; |
而应该理解这种更接近业务本身的表达:
Opportunity（机会） stage = Proposal（阶段为「提案」） —— 甚至就是一句人话： 「找到阶段为 Proposal 的销售机会。」 |
Agent 真正需要知道的,是业务层面的东西:机会是什么、金额是什么、阶段是什么、负责人是什么、机会和客户是什么关系。
它不应该被迫去理解这些纯粹存储层的细节:表怎么命名、join 怎么写、外键怎么连、索引怎么建、数据怎么分区、某个数据库特有的语法怎么用。这些东西,对 Agent 理解业务毫无帮助,只会增加它出错的机会。
所以,数据库抽象对 AI 的价值,不只是让代码更容易迁移这种工程好处,而是——它让 Agent 面对的,是更接近业务语义的抽象,而不是一堆存储实现的噪声。Agent 越是面对业务、远离存储细节,它就越可靠。
六、Object，是 Agent 的数据入口
之前讲过:AI 通过 MCP 进入业务系统。那么进入之后,Agent 看到的到底是什么?
不该是这些存储层的东西:
Tables（表）· Schemas · SQL |
而该是这些业务层的东西:
Objects（对象）· Fields（字段） Relations（关系）· Actions（动作） |
把整条链路连起来,是这样的:
Business Metadata（业务元数据） ↓ Business Object（业务对象） ↓ ObjectQL ↓ MCP / API ↓ AI Agent |
这条链路说明了一件事:Object,是连接数据、Runtime、Agent的一个关键中间抽象。数据往上,通过 Object 变成业务语义;Agent 往下,也通过 Object 触达数据。它是那个枢纽。
七、数据库 Schema 和业务 Metadata，到底差在哪？
用一张对照表,把抽象层级的差别讲清楚。
数据库 Schema（怎么存） | 业务 Metadata（业务是什么） |
Table（表） | Object（对象） |
Column（列） | Field（字段） |
Foreign Key（外键） | Relation（关系） |
SQL Query | ObjectQL Query |
DB 约束 | 业务校验（Validation） |
DB 权限 | 业务权限（Permission） |
Trigger（触发器） | 业务动作 / 工作流 |
重要提醒:这张表不是说两列一一严格等价。它是为了帮你理解抽象层级的差别——左边这一列,回答的是数据怎么存;右边这一列,回答的是业务是什么。它们在不同的层,解决不同的问题。
八、为什么 Business Object First 可能更适合企业软件？
至少有五个层面的解耦好处。
1 存储解耦。
业务不再直接绑定某一个数据库,换存储不用重写业务。
2 API 解耦。
API 可以围绕业务对象来设计,而不是围绕表结构来暴露。
3 UI 解耦。
界面可以由对象 + 视图驱动( Schema 驱动 UI),而不是硬编码某张表的字段。
4 Agent 解耦。
Agent 面对的是业务对象,而不是 SQL——这正是前面几节反复强调的。
5 治理集中。
权限、校验、审计,可以在业务对象这个更上层的地方统一执行,而不是散落在数据库、后端、API 各处、各做一套。
把这五点画成一张图,业务对象成了那个共同的中心:
Business Object（业务对象） │ ┌──────────┼──────────┬─────────┐ ▼ ▼ ▼ ▼ Data API UI Agent |
九、但 Database First，并不会消失
要明确:数据库依然是 Runtime 的基础设施,而且是不可或缺的。有一大堆问题,永远必须落到底层数据库去解决——
事务（Transaction）· 索引（Index）· 查询优化 并发（Concurrency）· 复制（Replication）· 备份 分区（Partition）· 存储成本 · 性能 |
这些,没有一样是业务对象层能替代的，所以：
Business Object First，不是 Database-less（没有数据库）。
它真正的意思是:数据库,从业务模型的定义者,退回到业务模型的执行载体。过去,是数据库的表结构定义了你的业务长什么样;而现在,是业务对象定义业务,数据库负责把它可靠地存下来、跑起来。定义权上移,执行权下沉。
十、ObjectQL：统一的业务查询模型
根据当前仓库,ObjectQL 提供的是一套统一的、面向业务对象的查询能力(CRUD、查询构建、过滤、排序、聚合、关系、批量等)。它的妙处在于:同一套 ObjectQL,可以被系统里各种不同的入口共同消费——
ObjectQL（统一业务查询） │ ┌─────────┬───────┼───────┬─────────┐ ▼ ▼ ▼ ▼ ▼ UI REST SDK MCP Automation |
这意味着一件很省事、也很关键的事:UI、REST 接口、SDK、给 Agent 的 MCP、自动化流程……这些不同的入口,不需要各自去重新理解底层数据库。它们说的是同一种业务查询语言。底层数据库怎么变,它们统统不用管——因为它们面对的是 ObjectQL,不是数据库。
一套统一的业务查询模型,让人、程序、Agent查询业务数据时,说的是同一种语言。这比支持多少种数据库,是一个高得多、也有价值得多的事情。
十一、如果数据库只是 Driver，谁才是真正的真理之源？
如果数据库退化成了一个可替换的 Driver,那么一个根本问题就浮现了:企业软件的真理之源——那个关于业务,最权威、最该被信任的定义——到底应该是什么?历史上有三个候选:
时代 | 它的 Source of Truth |
传统软件 | 数据库 Schema |
低代码 | 配置（Configuration） |
AI-Native | 业务元数据 / 对象模型（Business Metadata） |
那么,什么样的东西,才配得上做真理之源?它应该满足这些条件:可读、可验证、可版本化、可审查、可执行、能被人理解、也能被 Agent 理解。
用这些标准去衡量,你会发现:业务元数据比数据库 Schema,更接近 AI-Native 企业软件的真理之源。因为数据库 Schema 是给机器执行的、是存储导向的、人和 Agent 都不容易直接理解;而业务元数据,天生就是为表达业务、被人和 AI 共同理解而生的。
十二、这会让数据库越来越不重要吗？
明确回答:不会。恰恰相反,数据库可能会变得越来越基础设施化——就像电和自来水,越重要,越沉默,越不需要你时刻惦记。
这里有一个恰当的类比。软件的发展史,一直是关注点不断上移的历史:
早期：程序员直接关注CPU / 内存 后来：交给了操作系统 再后来：交给了运行时 / 框架 |
每一次上移,底层都没有消失,只是沉到了更下面,变成你可以信赖、不必时刻操心的基础设施。企业软件的数据层,可能正在经历同样的上移:从Table / SQL,上移到Object / Runtime。
数据库不是消失,而是被抽象到了更下面。它依然在那里、依然关键,只是你不再需要让整个业务架构,都围着它的表结构转。
十三、这种架构，会怎样改变企业软件开发？
落到开发者每天的工作上。传统的变更路径是横向的:
传统：改一个 Customer 字段 Database → Backend → API → UI → Agent （每一层都要动手改一遍，一处不能漏） |
而业务对象优先的路径,是纵向的:
业务对象优先：改一个 Customer 字段 改 Business Object（一处） ↓ 下游能力随之同步 |
(说明:下游具体能同步到什么程度、哪些自动哪些仍需处理,须以 ObjectStack 当前仓库的真实能力为准)
核心判断:业务变更的传播路径,可能从横向地修改多个实现,变成修改一个更高层的定义。你改的是业务是什么,而不是五个地方各自的实现。
十四、为什么这对 AI Coding Agent 特别重要？
一个 Agent 的成本,不只是生成 Token,还有一个更大的隐性成本——理解上下文。
传统架构下,Agent 要改一个业务概念,它必须跨层去理解一大堆东西:数据库、后端、前端、API、测试、配置……它要在这一整片散落的实现里,拼出这个业务到底怎么运作。
而业务对象优先的架构,Agent 面对的是压缩过的、业务语义级的表示:
Customer · Field · Relation Action · Permission · View |
这是一次实实在在的上下文瘦身:更高层的数据抽象,可以大幅减少 Agent 必须理解的实现细节。Agent 不用再去啃那一大片跨层的代码,它面对的是业务语义压缩之后的系统表示——看得更全,也更不容易迷失在细节里。
十五、ObjectStack 当前架构，为什么值得研究？
回到仓库。把 ObjectStack 在这件事上的结构画出来,下层是这样——业务对象经由 Runtime、ObjectQL,落到不同的存储驱动:
Business Object（业务对象） ↓ ObjectStack Runtime ↓ ObjectQL ↓ Driver（驱动） ┌────┼─────┬──────┐ ▼ ▼ ▼ ▼ PG MySQL SQLite Mongo |
而上层,同一个业务对象,又向多个入口敞开:
Object（业务对象） ↓ REST · SDK · UI · MCP |
这两张图合起来,说明了一句很关键的话:ObjectStack 并不是把数据库藏起来,而是在数据库之上,增加了一个业务语义层。数据库还在、还是那个可靠的数据库,只是它上面多了一层业务对象,让业务不再直接贴着存储。
在数据库之上增加一个业务语义层——这句话,比ObjectStack 支持多数据库准确得多,也有技术价值得多。前者说的是架构层次,后者只是一个功能点。
十六、Business Object First 的边界
1 性能。
抽象越高,就越可能损失掉针对某个具体数据库的特定优化的机会。通用的代价,往往是极致性能上的一点让步。
2 复杂查询。
有些复杂的分析场景,可能仍然需要直接写 SQL、写原生查询、用某个数据库的特有功能。不能假设一个统一的查询层,能优雅地覆盖所有查询需求。
3 数据迁移。
如果业务语义层成了真理之源,Schema 迁移、数据迁移的复杂性并不会消失——它只是从数据库层挪到了元数据层,位置变了,难题还在。
4 元数据复杂度。
业务对象的定义一旦变得极其复杂,元数据本身,就可能膨胀成一个新的复杂软件——你只是把复杂度换了个地方放。
5 数据治理。
真正的企业数据治理——血缘、留存、合规、备份、数据驻留——这些,依然必须落到数据库 / 基础设施层去解决,业务对象层管不了这些。
十七、未来企业软件，可能出现四层真理
过去,业务是什么和数据怎么存是重叠的——数据库 Schema 既是存储真理,也几乎就是业务真理。而未来,这可能会分化成四个不同的层,各自负责一种真理:
真理层 | 由什么承载 | 回答的问题 |
业务真理 Business Truth | 业务对象 / 元数据 | 业务到底是什么 |
交互真理 Interaction Truth | UI Schema / 动作 | 人和系统怎么交互 |
执行真理 Execution Truth | Runtime | 业务怎么被执行 |
存储真理 Storage Truth | 数据库 | 数据怎么被可靠地存 |
关键的变化是:过去,存储真理几乎约等于业务真理(数据库结构就代表了业务)。而未来,这两者可能逐渐分开——数据库负责怎么可靠地存,业务对象负责业务到底是什么。它们各司其职,不再混为一谈。
十八、表不再是企业软件的最高抽象
世界是由什么组成的 | |
传统企业软件 | 世界是由「表」（Table）组成的 |
对象驱动软件 | 世界是由「业务对象」（Business Object）组成的 |
AI-Native | AI 需要理解的是「业务对象」，而不是「表」 |
从 Table 到 Object，不只是数据库抽象的升级， 更可能是企业软件从存储中心，向业务语义中心的一次迁移。
结语
回到最开始那个问题:Customer 到底是什么?
它不是一张表。它是一个业务概念——一个可以被人理解、被 AI 理解、被查询、被操作、被治理的业务对象。而那张 customers 表,只是它众多可能的存储实现之一。
所以,最后说清楚这件事的分寸:数据库当然不会消失。SQL 不会消失。PostgreSQL、MySQL、MongoDB 也都不会消失。真正在变的,可能只是它们在企业软件架构里的位置。
当业务对象拥有了自己的元数据、查询、动作、权限和运行时之后,数据库更像是怎么把业务可靠地落地,而不再是业务到底是什么的唯一答案。从 Database First 走向 Business Object First,不意味着数据库退场——
它意味着，业务语义，终于可以从数据库里被解放出来。
对人来说,这是一层更好用的软件抽象。而对 AI Agent 来说,这可能更重要——因为 Agent 真正需要理解的,从来不是一张表,而是这张表背后,所代表的那门生意。
说到底:数据库解决的,是把数据可靠地存起来;而企业软件真正要解决的,是让机器和人,都理解这些数据所代表的业务。
——本文以 ObjectStack / ObjectQL 开源项目为案例进行技术分析。涉及仓库能力的部分,以其当前公开源码和文档为准;凡涉及「数据库真理之源上移」「业务对象成为主要抽象」「Database First 向 Business Object First 演化」等,均为作者的架构趋势判断,非既成事实或行业共识。文中示意代码仅用于说明抽象层级,非仓库确切语法。
ObjectStack · ObjectQL · 开源的 AI-Native 企业软件运行时