pm|产品领域的元宇宙：aPaaS产品解构( 二 )

那不妨抽象一下，当我们研发一款SaaS应用时，我们做了哪些事情。为了方便理解，我拿大家最熟悉的CRM系统来做case。试想一下，落地一款CRM软件总共分几步：

定义线索、商机、客户、联系人、跟进记录实体
设计实体的数据结构、字段、索引
为每个对象定义CRUD接口、数据校验逻辑、业务规则校验逻辑
设计权限、审批流程、定时任务
前端、移动端页面开发
报表功能设计开发

这6步几乎是一个标准CRM应用的研发流程。如果你是一个运营了10万名销售的业务leader，选择这样的标准“定制化开发”模式做一套CRM是没问题的。但如果你的业务量过小，定制化CRM的ROI极低；更极端的场景是，如果你的10万名销售业务模式迥异，需要10套CRM来支撑呢？这个时候，我们需要一种低成本开发CRM的方式，才能让ROI打正。并且这种方式，需要能够拉通底层数据，避免独立搭建10套CRM带来的数据孤岛问题。

降低边际成本->复用和抽象是关键
打破数据孤岛->数据底层必须一套

于是aPaaS产品的底层思路就产生了：只要把研发过程中的实体含义、数据结构、CRUD进行抽象，把数据和含义解耦，让“含义”支持自定义，这样数据层面就会非常干净纯粹，适合复用。举个例子来说，当我们需要一张“线索数据表”，传统的方式是我们定义好“线索数据表”的每个字段完成建表。而将含义解耦后，我们只要让“线索数据表”的描述变得可自定义配置化，就可以将无数这样的业务表，都集合到统一的元数据层面，实现元数据（Meta）的抽象和复用。
进而，如果这些元数据支持权限、租户管理，也就实现了既能打破数据孤岛进行交互，又能多业务兼容互不影响的效果。具体点说，就是这SaaS模式下，我们生产的是“成品地板”，这样的问题在于如果有新的地板拼装样式，我们很难调整生产线。但在aPaaS模式下，我们把生产线拆成“木头生产”和“地板拼装”两步，只要保持木头的生产，同时不断更新“地板拼装规则”，就可以源源不断地适应各种“成品地板”需求。
所以，aPaaS产品实际上是定义了一套标准化的“地板拼装规则”和能够识别这个规则转化成拼装动作的“地板拼装规则识别机器”，这个机器就是能够联系meta和data的“元数据引擎”。
2. 数据实体实现方法

文章插图
【 pm|产品领域的元宇宙：aPaaS产品解构】思路理完，具体实现层面上，关键点在于“元数据引擎”的构建，以及meta和data之间的联系。为了实现“地板拼装规则”的逻辑，需要把所有可能出现的“规则”进行抽象。
这里实现层面用的是field类型，而不是column类型，二者的区别在于：
A column is collection of cells aligned vertically in a table. A field is an element in which one piece of information is stored, such as the eceivedfield.
Usually, a column in a table contains the values of a single field. However, you can show several fields in a column by using a Formulaor aCombinationfield. Fields can also be shown as rows in a card view or as controls on a form. A column is just one way to display the contents of a field.
翻译过来的意思是“column只是field的一种存储形式”。举个特别形象的例子，你的一个excel表格，就是一个data表，表头有3列，分别是姓名、性别、年龄，这3列就是column。而姓名列是text文本、性别是布尔值、年龄是数值需要支持大小排序，这三种规则就是通过meta对象模型来实现的。
我们事先定义好了文本、性别布尔值（男、女、其它）等规则，用object+field的对象模型规则存储下来，支持column去使用，即可实现上面提到的“数据和含义解耦，从而元数据可复用、描述可配置”。