海比研究院专访有信云产品VP：个性化的问题必须通过引擎的思想来解决

近日，中国软件网、海比研究院共同发起了关于2022中国低代码无代码市场研究访谈，有信云产品VP郑秋明受邀进行了线上交流。

低代码刚出现的时候，市场概念相对朴素，用户较容易理解。各类厂商入局后，为了提升差异化竞争能力，纷纷提出各种概念，例如表单驱动、模型驱动、数据驱动、工作流引擎等。对此，海比研究院的行业专家与有信云产品VP郑秋明进行了长达2小时的线上访谈，深入交流了关于低代码、无代码的市场环境及有信云自身的理解与实践。

由于访谈篇幅较长，现摘录部分分享，也欢迎各位行业大咖共同分享与交流。

Q - 海比研究院

A - 有信云产品VP郑秋明   

---

Q：我们访谈过很多业内的厂商，发现大家会着重提到表单驱动、模型驱动和数据驱动，在您看来这三大驱动是指什么，之间的差异点是什么？

A：厂商已经把驱动讲成一种营销话术了，某某驱动听起来就很高级，实际这三个驱动是针对不同场景的，且不是一个分类关系。

先说说模型驱动，早在2000年左右就已经开始提了，本质是一种比较通用的软件思想。模型来源于业务，业务是场景下的业务，因此需要将它抽象成可视化的模型，从而把这一个复杂、多细节的业务抽象成几张图，可视化的去理解。

今天大部分的软件开发，包括低代码、无代码都是模型驱动的。而模型背后的核心是对象关系。商品是对象，订单是对象，商品和订单是什么关系？一个复杂的系统，可能有几百个对象，把对象连接起来，这就是一个基础的模型，这是我理解的模型驱动，它其实是蛮通用的思想。

而表单驱动与数据驱动是业务上的说法。市面上很多低代码、无代码平台抽丝剥茧后即是一个个表单，里面填一些数据，填完数据之后可以提交、浏览、删除。数据驱动跟表单驱动还有点相对，不太一样的地方在于对业务数据的处理。比如做可视化图表，数据表跟数据表之间怎么连接？连接后怎么做可视化的报表、可视化的图形？怎么对业务进行支持？这就是数据驱动。

所以三者还是比较抽象的营销话术。对于普通用户或甲方企业而言，根本不需要在乎。

不管你什么驱动，只要能够满足我的问题就行了。

Q：低代码、无代码，表单驱动、模型驱动、数据驱动，两组概念之间是否存在对应关系？

A：完全没有。

比如模型驱动，通常不是用于低代码、无代码场景的，而是近二三十年来软件编程的一直遵循的模型思想。所以模型驱动还是蛮普遍的，不局限于无代码、低代码、SaaS，做个电商也会需要。

表单和数据，部分厂商可能只做了表单，没有很强的数据，但个人觉得一个好的无代码或低代码平台，一定是表单+数据的，只是有一些侧重。否则业务很难闭环，很难给甲方提供一个真实可用的应用。

Q：但从终端客户角度，三者（驱动）给人的直观感受是表单驱动更传统简单，而模型与数据驱动更贴合IT变DT时代调性。

A：确实，且我看到的大部分平台三种驱动都有。如果问我们是什么驱动，我们不说驱动。在有信云PaaS平台上，我们称之为引擎，来源于对不同业务场景地抽象，不同的引擎对应着相应的能力。

Q：刚才讨论了市场大环境的一些看法，也有聊到有信云，那就麻烦郑总介绍一下有信云和刚提的引擎吧。

A：有信云的一站式业务在线PaaS平台，最早从18年开始。有信云与其他厂商最大的差异在于有信云是做社交电商市场起步的，当然也有像经销管理、门店管理，当年我们甚至根本不知道什么是低代码无代码。

现实中的问题是我们接触的每一家甲方公司，诉求都不一样。有信云一直服务的是KA，因此很难做一个标准化产品。理想中是做一个经销商管理系统之后，A公司可以用，B公司可以用，C公司也可以用。但市场不是这样的，哪怕是订单。A公司订单不校验库存，可以超卖；B公司订单要限购；C公司订单有很多会员规则。

怎么办？有信云一直在思考这个问题，慢慢地积累了一些独有的能力——对客户具体的业务场景进行抽象，形成了一些业内大家常说的引擎。

我们发现个性化的问题必须通过引擎的思想来解决。如社交电商一定要分钱，怎么合理地分给一级代理商，二级代理商？按地区来分，按团队来分，按商品来分还是按什么分？于是有了有信云PaaS上的分佣引擎。不管怎么分，都可以通过引擎写几行代码分到、分好。

再比如每个公司都有自己的流程，要不要库存校验，要不要限购，要不要会员价等等。于是就有了所谓的订单流，订单流本质上是一个流程引擎，订单是它的一种场景，然后跟着做了售后流、审批流、业务流等，于是把它抽象成了一个流程引擎。

但哪怕电商场景已经足够复杂，仍有很多场景是不能穷举的。于是，如商品、订单等我们称之为标准对象，依此类推如果是做会议室管理，对象就是会议室；想做进销存肯定就有库存对象；比如我们有客户是做核酸的，核酸检验报告的提交表单就是一个对象。这些帮助我们抽象出了对象引擎，慢慢就有了很多个引擎相应的能力。

之后逐渐接触到了低代码、无代码，发现我们并不像国内的很多其他厂商，学着国外的产品起来的。国外早在80年代就有了低代码的概念，低代码、无代码的市场理念与产品形态是从国外起家的。

而有信云从电商应用起家，电商里又分了门店、经销，发展到现在我们发现自身有几个很大的差异点，这里可以分享一下。

第一，有信云是国内唯一一家做企业外部经营数字化的低代码公司。简单来讲，你去问国内比较知名的低代码厂商能不能做一个电商应用？他们会说不行，因为我们真的去问过，基本都是做CRM类的。

Q：为什么做不出来？在他们的低代码平台上。

A：这里就涉及到第二个差异点。有信云也是唯一一家可以将订单流、退货流、商品流等流程可视化的低代码公司。

电商应用是外部连接应用，它有几道很重要的坎。

第一点，它的连接范围是最广泛的。现在市面上绝大部分低代码、无代码厂商的连接范围是企业内部，有信云PaaS的连接范围包括企业内部、合作伙伴，尤其是经销商、代理商、广告商等等，最后就是C端客户。

第二个坎是电商相关流程的配置能力可视化难以实现，因为电商是极其复杂的。光商品就有十几个对象。商品本身有单品，然后有商品规格、商品价格、商品详情，还有对象之间的关系，才构成了商品本身。商品复杂，订单又很复杂，店铺也很复杂，支付也很复杂，人货钱场单都很复杂。所以有信云预制了这些，像前面提到的，不要限购，要预售，要会员价等等，在有信云的PaaS平台可以直接配置和调整。

第三个坎是并发。为什么很多国内的to B应用不好用，或者说用起来慢、卡？本质原因在于用户量不大，都是企业内部人员用，并发的支撑能力并不强。但一个电商应用，有信云部分客户一次秒杀可能就过来几十上百万人。外部应用对并发量的要求非常之高，对于技术架构也是有要求的。

国内的大部分低代码、无代码平台核心架构还是宏服务，所有的对象放一起。有信云的微服务架构可以让需要高并发的场景单独做成微服务，每个微服务之间，内部高聚合，外部低耦合。再之，我们做了很多这种技术上的优化与迭代，使得在外部的高并发场景下都能满足。

这三个门槛，导致大部分的低代码、无代码平台做不了外部业务数字化的应用，尤其是以电商为代表的这一类应用。这也就是我们的第二个差异点。

第三个差异点，在国内低代码领域，有信云是唯一一家推出自己的DSL语言的公司，命名为EXAP。EX即拓展，extension，APP则是application，应用，即应用拓展。EXAP是一个类Java的语言，但语法量是Java的1/50。

DSL，D代表着domain，只适用于我们的领域，代码导出后是无法使用的。只适用于有信云PaaS，意味着我们可以把这东西做得很简单。

比如写订单模块，起码要有5年的后端开发经验，对订单模块非常之熟悉。但在有信云PaaS上不需要。你可能只是一个大专毕业生，要嵌一段代码去校验一下订单的库存，只需要拖一个组件过来，用DSL语言写一小段代码，就可以跑通整个订单流。它不需要一个资深的Java开发，只需要理解业务逻辑，懂一点代码，就可以写复杂的订单应用。