市面上有不少用于推进某些业务的表单设计器，例如轻流、有道云等，它们的理念是用一个很小的表单和流程，解决企业的细小业务，可以理解为问卷收集基础上的流转能力。但是，对于开发者而言，往往需要面临比这类细小业务复杂的多得多的业务流程，以及流程节点上的表单。我在该领域持续研究了三年多，这些研究有静态的，也有动态的。所有动态化，有两个角度，从产品运营人员的角度，处于流程中的表单可能随时需要调整一些策略，例如字段的限制，或者某些字段的增删；从开发人员的角度，我们不能用代码限定死表单及其囊括各方面的内容，而是需要在前后端配合下，异步的生成表单的界面、交互、业务逻辑等等。本文将梳理我的设计思路。

动态建模

对于表单而言，我推崇先建模，当然，建模并不只适用于表单场景，任何场景都适用，只是需要考虑成本。但在建模时，我们往往需要去思考，在业务层面，我们需要什么，在交互层面我们需要什么。虽然这两类东西是不同的，但是在最终的产品形态上，它们不可能分离，只能放在一起，因此，在面对用户时，我们需要有一个较强的分类的设计，让用户在使用使不会懵圈。当我们尝试去动态化建模时，就不得不考虑这些问题。

元数据

我们的模型是由字段组成的，但是字段并不是最小单位。用于描述字段的数据，我们称为元数据，它是dataset级别的数据集，组成字段元数据的，我们称为属性，是atom级别的数据。每一个属性，往往只存在值，而不会再有其更深的元数据，因为我们会以定义的形式赋予其意义，而非描述它的意义。

我个人将字段元数据分为3个部分：字段的存储性质；字段的逻辑性质；字段的交互性质。

字段的存储性质可以理解为如果我们要把该字段存储在数据库中所需要的属性，当我们在使用 create table 语句时，我们就会规定字段的存储性质，例如字段的数据类型、默认值、长度、名称文本、字段解释（含义）等等。这些信息是固定的，对于字段而言，无论在任何场景下，都是死的，不变的。除了上面列出来的这些和数据库对应的属性，其实我们还会有一些和业务中关联的属性，不同的业务系统，其关联的属性必然不同。例如在付款系统中，对于数值，它可能还存在一个是否代表金额的属性，因为普通的数字和金额在使用过程中，有非常大的区别；例如对于账户类型的字段，你需要考虑，它是存单个，还是多个账户；例如对于日期字段，你需要考虑是否要使用UTC，还是使用字符串。不同业务系统中，我们都会通过不同的属性来定义我们的字段，而这些定义具有强制性，在本业务系统中，必须如此，不可更改。

字段的逻辑性质，也可以理解为在业务流程中随着业务推进而带来的逻辑变更。例如某个字段的必填属性，在不同业务阶段，其必填逻辑是不一样的。字段的逻辑性质主要是一些校验属性，例如必填、长度、数值区间、数值位数，以及在不同流程阶段该字段的可见性等等。这些属性也是本业务系统中规定的，但是具有可变性，不同场景不相同。对于我们动态化设计而言，实际上这个部分是最难的，也是用户们最想要的。用户们会觉得这类需求并不复杂，因为它们会从结果出发，但是对于研发而言，这类需求是最复杂的，因为它设计前后端无数的架构和设计细节。

字段的交互性质可以理解为字段的呈现性质，这些性质往往不影响业务推进，主要是对界面和交互产生影响，不存在也无所谓。例如对日期的格式进行规定的属性，对数值的格式化的属性，对字段提交到后端接口时所要呈现的结构或格式的属性等等。这些属性虽然不是最重要的，但是在系统中是最好实施的，最容易看见成果的，因此我是比较推荐先从这个部分的动态化实施，慢慢扩展和研究全部的动态化。

元模型

模型是基于字段集搭建的描述体，但具体到某一模型，我们会发现，它是多态的，场景化的。或者换一种解释，同一个对象，在不同场景下，它所拥有的字段、逻辑，可能不一样。例如一个付款，在通常情况下，我们需要呈现它的全部字段，而且往往还会将它关联的双边付款银行作为子信息。但是，在某些场景下，我们并不需要关心它的全部字段，而是只呈现它的个位数字段。同样是一个付款，不同场景下所拥有的东西不同，这似乎不成立，难道它们是不同的付款？实际上，我们知道，付款还是那一个付款，其背后的实质是一样的，只不过在不同场景下，它披上的衣服不同，遮住了不同的部分。我们将有关付款的本质模型称为元模型，即模型的模型。而具体某个场景的模型，则是其元模型的收窄，这和我们编程中的子类型相反。

梳理元数据的表格

在开始编程之前，我们要通过excel表格，梳理现有系统的元数据，这在将来我们完成动态化开发后，直接利用该excel进行导入进行动态化系统的初始化也有帮助。梳理元数据其实很简单，你可以理解为用excel表格把每个字段的各个方面描述一下，而且一定要细，拆分也要准确。

这里举了一个非常简单的例子。我们在开始开发之前，要去梳理这些元数据。而且不同的业务系统，这些元数据都会完全不同，且随着开发的深入，我们还会在继续深化，增加新的属性，或者将原来的一个属性拆分为多个属性。

设计元数据Schema结构

由于我们的目标是动态化，因此，我们需要把这些元数据信息存储在后台，从而可以实现在线的编辑功能。 我们要将字段的元数据存储在数据库中，在管理平台上可以编辑它们，并完成保存，同时，在用户界面拉取出来进行表单的渲染。从元数据的特征来看，它天生是一种键值对的非关系型数据，因此使用NoSQL数据库是一个不错的选择。我们可以把具有嵌套结构的数据存储在一个数据中，同时，元数据属性又不会用于查询。因此，有一种扁平的描述性强的数据格式非常有必要，我们称该数据格式为Schema，即在特定场景下的产品描述协议。

而基于Schema的描述格式也非常重要，这里面有非常多不确定的动态因素，而大部分数据格式都是静态的。如何才能更好的适应这种意图呢？我们需要设计一门动态DSL语言到我们的Schema中，用于表述具有动态逻辑的部分，特别是在上面提到的字段的逻辑性质。

设计动态DSL语言

我们不是要发明一门编程语言，我们是要解决动态化表单过程中，如何让描述文本具备更深的动态含义。解决眼前的问题，有利于我们减少瞎想乱想的可能性。简单讲，我们在使用静态的文本描述元数据和模型的时候，我们只需要支持这种动态化即可，不需要再深入提供编程能力了。

DSL需要以Schema作为宿主，Schema是描述协议，是完整描述元数据和模型的文本，而DSL是Schema中的组成部分。

上面这张示意图表现了编辑一个字段元数据的界面，这个界面虽然只关乎一个字段，但是它的内容非常多，甚至有的时候极其复杂。

Meta Market

我们完成元数据的梳理后，把元数据导入到数据库中，以Schema的格式存储它。接下来，我们就要使用这些字段。不过，在真正开始操作之前，我们需要引入一个 Meta Market 的概念，即基于元数据的字段的集合。对于某一对象实体而言，它的字段的总和，我们称为 Meta Market，用以作为在动态化建模时的备选。Meta Market 和元模型息息相关，我们甚至可以认为，很多情况下，Meta Market 和元模型是一个事物的两面，元模型是从一个完整概念的角度陈述对象的抽象，而 Meta Market 则是从一个将完整概念拆分成各个部分的角度陈述对象的组成。一般而言，一个 Meta Market 或元模型等价一个完整的业务对象，不过这种“等价”是不存在的，因为几乎我们不可能在某个场景下，使用到该总集，我们肯定确定以及一定，是在具体场景中使用它的收窄。

Meta Market 存在的意义，是让用户在操作时，有一个范围。例如，当用户在进行支付的建模的时候，他一定只能从支付的字段中去选择，而没有必要把跟支付无关的字段拉出来让他选择。Meta Market 是一个集合，同时，也是一种抽象，我们可以利用 DSL 来在 Meta Market 提供一种可选项，让用户有机会在没有创建出模型之前，还能有机会去设定模型的能力。

场景对于一个业务系统来讲，是固定的，有哪些场景，基本上是写死的，在代码中是耦合的。

场景实体

实体是基于 Meta Market 的具体化，是基于元模型的收窄。例如支付，此时我们要结合具体的场景来设计该实体。例如当我们的支付已经进入到统计的场景时，只需要拉取于金额、数量相关的字段，而类似成员、商品名称等，就不需要涉及。实体，是我们动态建模的最终阶段，当我们在面临新建支付的场景时，我们需要构建该场景下的支付实体，而当我们进入到统计的场景时，需要构建统计场景下的支付实体，虽然它们都是支付的实体，但是它们是不同的。在这个过程中，我们使用了相同的 Meta Market 构建了不同的实体。

从用户的使用角度，我们不应该让用户去主动构建实体，而是应该将其蕴于构建表单的过程中。因为从用户的角度讲，他们更关心看得见摸得着的表单，而不是相对来说更底层的实体模型。

另外，一旦遇上场景，那么在元模型的收窄中，会将元数据的规则也收窄，例如上述付款金额，在发起支付和生成报告两个场景下，其是否可以编辑的逻辑不同，因此，到了具体的场景下，在实体中所呈现出来的结果也不同。

（注，大部分情况下，我们并不直接编辑模型，而是结合表单界面进行编辑，只有在某些调试情况下，开发人员可以通过编辑来调整细节。）

接入数据源

最后，在建模体系之外，我们还需要有一种方式，可以接入到系统已有的数据源，或者我们自己创建另外一个系统来为表单系统提供数据源。数据源指当用户在使用表单时，可以读取的关联对象的引用。比如我们有一个字段叫“地区”，当用户在填写表单时，需要去选择国家-省-市的地区，但并非我们需要列出全国的所有地区，我们可能只需要列出本公司有业务往来的地区即可。地区数据并不存在于表单系统中，而是在业务系统的另外一个地方进行维护，因此，我们需要有一种方式让表单系统可以接入该数据源。无论是在编辑字段元数据时，还是在用户填写表单时，这些数据源往往起到非常重要的作用。

除了类似“地区”“行业”“阶段”等业务层面的静态数据源，还有“已办事项”“待批申请”等等处于业务流程中的动态数据源，前者我们往往称为值对象，后者往往称为实体。虽然两种数据源本质不同，但对于“接入”这件事而言，表单系统需要抹平这种差异，它们都是数据源，因此在引入时应该通过中间服务将其统一为一种格式。

上面这张图中，假如我们有一个选项类型字段，意味着用户在填写表单时，该字段要从选项中选择，而选项的来源可以是我们自己创建，也可以通过选择一个数据源作为选项列表。而在这些备选数据源中，行业、区域是值对象，审批列表、支付列表则是实体。

动态表单

对于产品化的动态表单而言，我们应该让用户进到产品里时，就可以立即进行表单设计。在表单设计过程中，再让用户来细化字段。这也就意味着，字段不是提前准备好的，也无法在传统关系型数据库中提前定义字段和表结构。当用户在创建一个可输入的输入框或类似的组件节点时，我们需要将该节点与对应的字段予以绑定，而在这个过程中，就需要用户自己去填写字段的信息，同时把创建好的字段放到数据库中。这和我们编程架构是完全相反的，我们程序员的思维是从底到顶，从打好基础再一层一层往上叠加，但是用户的使用是反过来的，他们需要先看到自己想要的，然后再去一点点补充细节，这就导致要实现这样的产品，对于我们开发人员而言，是一个非常大的挑战。

梳理表单组件

表单组件有4大类：控制表单状态的组件、表单布局组件、通用数据填写组件、业务特性的数据填写组件。不过对于用户而言，就分为两类，一类是布局组件，一类是数据组件。而且对于相对简单的表单而言，我们甚至可以直接忽略布局组件，用户使用时只会考虑数据组件。

数据组件分两大类，一类是通用的，一类是和特定业务或数据源绑定的。例如，我们可以提供一个区域选择器组件，这个组件它是直接和区域数据源绑定好的，不需要在利用最原始的选项组件去拼命找数据源。但是，这里需要注意，如果封装的业务组件过多，一方面是用户在创建时眼花缭乱，不知道要选哪一个，还有一方面是一旦需要调整数据源，就不得不修改代码，与我们动态化初衷相违背。因此，我认为只有那种非常非常复杂的业务组件需要提供，如果是可以利用通用组件配置出来的，我们可以提供一个配置的导入功能，将一些通用的配置直接快速导入，例如区域、行业等，这些配置其实都比较简单且统一化，可以使用导入的形式，一键导入，同时又可以在导入后继续修改。

在表单组件命名时，数据型组件我通通用动词而非名词，这样可以避免与其他组件产生混淆。例如不叫 Textarea 而叫 InputText, 不叫 Switch 而叫 Toggle，诸如此类。

界面编辑器

实际上，界面编辑器存在通用的方案，只不过针对表单，我们可以将界面编辑限定在特定组件内，因此，表单的界面编辑是通用界面编辑的子集，而且，由于使用场景的限定，我们就可以针对编辑器做一些定制和优化。例如表单的布局，由于一个系统中，表单的布局是确定的，因此可以把布局内嵌到画布中，而无需提供专门的布局组件。

通过表单界面编辑器，可以让用户先有一个直观的效果可以看。在此基础上，通过将输入组件与前文的字段进行绑定，即可更快的提供一种产品的运转模式。但是，其实这里面有很多细节值得商榷，例如某一个字段是账户列表，但是你非要将其绑定到一个文本输入框组件上，就显得非常不合适，因此，这些细节就不得不靠代码来控制，例如如果你插入了文本输入组件，那么就没有办法绑定账户类型的字段。当然，更好的方式是，当你准备绑定一个账户类型的字段时，系统提示“该字段为账户类型，需要使用账户组件进行选择，是否确定？”。通过自动切换来使得交互和字段的逻辑一致。

界面编辑的作用其实主要是布局，具体的表现和逻辑，大部分是通过右侧的配置来实现，右侧的配置可能会非常复杂，我们接下来会慢慢讨论。

表单Schema

用于描述表单的数据格式，阅读表单的Schema文件，就可以理解整个表单的逻辑和交互。对于表单而言，它包含多种要素：布局、指令、引用。布局比较容易理解，指令是只表单在遇到什么情况时应该执行什么样的动作，例如在提交时需要进行校验，当出现某种情况时要弹出一个警告框等等；引用主要是对相关资源的引用，例如对模型的引用、对数据源的引用、对接口的引用等等。因此，虽然表单的Schema文件包含了全部，但是作为普通用户，是无法阅读的，因为你需要去阅读其他内容才能获得完整信息，总之，它更像是一个索引文件，而不是一个打包文件。

虽然它是一个索引文件，但是基于它，我们可以构建出该表单的完整内容。

表单作用域

表单的作用域是指用于承载表单的数据的上下文，其中包含表单所对应的模型实体、临时变量、上下包含或引用关系等。每一个表单，都对应一个模型，这个模型承载了表单所对应的数据（字段的集合），模型是对业务的呈现，表单基于模型，也就基于了业务。但是单纯靠模型是无法完成所有交互的，在交互中，我们需要依赖一些状态值，因此，在表单作用域中，我们允许声明临时变量作为状态来控制交互。还有一种情况是，表单的布局中存在包含关系，例如支付表单，可能包含一个配送相关的子表单，虽然从逻辑上它们有层级关系，但是在交互上可能是平级的，因为一个支付只对应一个配送。还有一些是一对多的，这种就更能体现包含关系。

对于包含关系，我们要让模型之间建立引用关系，同时，我们可以把子表单独立出来，建立自己的独立表单，并且在表单之间建立引用关系。对于用户而言，用户不需要去考虑这背后的实现，只需要在界面上确保它们的包含关系即可。

插件式组件体系

作为通用表单设计器，它允许你自己开发自己的组件，并且在开发的组件中，附带组件的配置和各种逻辑，对于设计器服务方而言，我们将这些打包好的组件作为插件放入到不同用户对应的初始化信息中，从而他们可以使用自己开发的组件。

组件的设计包含两个部分，一个部分是如何在设计器设计界面中表现，其实可以使用静态图片接口，同时让用户上传一个icon作为组件在组件列表中的呈现；一部分是预览时真正呈现在界面中的效果，这部分需要真正的前端代码；还有一部分是配置部分，配置部分可以直接将它们作为一个小表单，直接使用我们的表单Schema作为配置文本。基于这三个部分，我们就可以让用户提供足以呈现完整交互的组件给到平台，让平台加载这些内容，进而可以让用户在平台上使用自己的组件。

添加组件时，可以选择平台组件商城中提供的高级组件，也可以让用户自己选择上传自己的插件包。

解决复杂问题

在实现动态化配置中，我们会面临几个非常复杂的问题，包括但不限于：字段的某些属性是根据其他字段的值动态得到的，应该怎么配置？怎么实现表单中可添加删除的列表数据？有些交互需要实时和后端接口进行通信往来，该如何处理这种情况？等等。

复杂问题往往意味着特殊性，其使用率会比较低，但是在业务开发中又不得不去实现，因此，我们应该将此类问题后延，等动态化体系完整实现之后，再来考虑这类问题。

针对字段属性的动态得到问题，我们有DSL，在配置中，我们让用户自己配置某些条件，在进行条件配置时，可拉取其他字段，配置后，按照一定规则，生成DSL放到Schema中，这样，在保存好的结果中，就是我们需要的Schema，不过在第二次进行编辑时，我们又要将DSL反向解析为配置界面上的内容，因此需要设计出更容易完成这类解析的DSL。

除了这里提到的这些复杂问题外，在实际开发中，我们一定还会遇到更多复杂问题，等待我们去解决。

结语

模型和表单动态化配置，是一种趋势，这种动态化配置从某种程度上讲，对业务方来讲，可以起到提升效率的作用，如果我们能够在工作中提供一套类似的解决方案，一定能更合理的帮助我们解决某些特定的需求，而且效率上一定是成几何级的提升。当然，这是一个广阔的领域，需要我们不断的探索，找到最终合适的产品形态。

2023-01-12 2142