aPaaS 本质是「运用开发」东西，那 aPaaS 产品自身便是从「全代码」-「无代码」中心的平衡

aPaaS 的解决方案是什么

因为 aPaaS 本质是「运用开发」东西，那 aPaaS 产品自身便是从「全代码」-「无代码」中心的平衡。

但是在产品设计上，其实二者的笼统思路仍是有很大的差异：

零代码是从业务层往下笼统，根据企业运用的通用特点，笼统对应的产品功用。

低代码是从技术层往上笼统，根据代码敞开的途径和东西进行封装，完成产品功用。

1. 零代码的笼统

简略的业务体系，业务层根本能够笼统为四个通用的部分：数据搜集、流通、存储、分析。对应零代码的首要功用模块如上：

• 表单
• 流程
• 数据存储
• 数据加工和 BI

一起，为了更大程度，下降用户的运用本钱，表单：数据表在结构关系上，根本是 1:1 绑定，部分产品流程：表单：数据表也是1:1:1绑定。在建立表单时，就完成了数据表的建立，一起能够根据表单建立对应的数据流程。此类架构，默许帮用户完成了前端和数据的绑定关系，极大下降用户的建立本钱，但也下降了灵敏性。如果业务期望建立个性化的前端界面或者是有灵敏的数据关系，或许就没办法完成。

这儿再次 call back 到上文提到的零代码产品在商业上的难点，许多零代码产品无法解决量的问题，到千万量级根本就会遇到营收的瓶颈。部分产品此刻选择的途径，或许是朝着低代码转型，强化其二开才能，进步客单价，个人认为，这不一定是好的思路，架构上的转向是很难的，要么另起新产品，要么仍是能够考虑下零代码在产品力上，怎么更好满足中小企业诉求，一起又能开箱即用，一起在渠道上，看怎么能更好找到中小企业的客户。

2. 低代码的笼统

从开发一个 APP 的研制工程来进行笼统，得到对应的产品才能：

• 数据库服务 – 数据表建立器
• 前端服务 – 页面建立器（封装好的一方组件、自定义组件）
• 后端服务 – 流程建立器
• 底层：FaaS 服务，支撑二开
• 测验运维：多环境、多分支
• 打包发布：发布办理

各模块之间相关独立，无耦合，能够经过调用和绑定来完成特定逻辑，比如页面需求展现指定数据，需求页面去主动查询获取指定数据而且绑定在页面组件。

优点是，产品极端灵敏+个性化，能建立千人千面的运用，问题是装备本钱极高。而到详细功用设计中，每个产品的封装程度各不相同，比如一些模型驱动的产品，为减少装备本钱，会经过一些装备，默许帮用户进行数据的绑定，而另一些产品则会更倾向于减少封装逻辑，满足原子化，操作权交给用户。