产品领域的元宇宙椅子套罩图片及价格( 二 ) _业务

设计权限、审批流程、定时任务

前端、移动端页面开发

报表功能设计开发

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

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

于是aPaaS产品的底层思路就产生了：只要把研发过程中的实体含义、数据结构、CRUD进行抽象，把数据和含义解耦，让“含义”支持自定义，这样数据层面就会非常干净纯粹，适合复用。举个例子来说，当我们需要一张“线索数据表” ，传统的方式是我们定义好“线索数据表”的每个字段完成建表。而将含义解耦后，我们只要让“线索数据表”的描述变得可自定义配置化，就可以将无数这样的业务表，都集合到统一的元数据层面，实现元数据（Meta）的抽象和复用。

进而，如果这些元数据支持权限、租户管理，也就实现了既能打破数据孤岛进行交互，又能多业务兼容互不影响的效果。具体点说，就是这SaaS模式下，我们生产的是“成品地板” ，这样的问题在于如果有新的地板拼装样式，我们很难调整生产线。但在aPaaS模式下，我们把生产线拆成“木头生产”和“地板拼装”两步，只要保持木头的生产，同时不断更新“地板拼装规则” ，就可以源源不断地适应各种“成品地板”需求。
所以， aPaaS产品实际上是定义了一套标准化的“地板拼装规则”和能够识别这个规则转化成拼装动作的“地板拼装规则识别机器” ，这个机器就是能够联系meta和data的“元数据引擎” 。
2. 数据实体实现方法思路理完，具体实现层面上，关键点在于“元数据引擎”的构建，以及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去使用，即可实现上面提到的“数据和含义解耦，从而元数据可复用、描述可配置” 。
这种设计当数据需要存储到data中时， data需要知晓每个字段是什么样的object ，也就是业务系统需要依赖于“元数据引擎” 。反过来，在业务系统在使用业务数据查询data时，也需要“元数据引擎”做好column+含义的处理。

3. 业务规则的实现方法有了数据实体，还需要有大量的业务规则。举个例子，拿线索实体来说：