现在接到一个新的项目就是客户下单，然后后台根据客户下的商品去安排快递和派送。
如果单纯用低代码平台是没法实现的，因为客户下单的界面类似一个小的电商网站。对于页面的要求比较高，用户体验比较高，这个低代码平台的表格化管理方式是不能够满足客户需求的。
但是从内部管理角度讲，用户下的所有订单又非常容易表格化，将订单中的物品排序之后，放入到不同的快递流当中来实现后台的物流管理。这个可以说是非常标准的企业化运作。实地代码发挥能力的场景。
还有在该项目建设当中，物料主数据业务数据，都要与企业ERP做对接，这个也不是低代码平台的擅长。
根据以上情况我想也许可以采用一种混编方式。
首先是通过低代码平台建立订单，商品，配送的数据模型，也就是说通过低代码的快速构建，对于这三个对象能够形成表单化的管理。
用户使用的商城和下单，则通过定式化开发来实现，也就是建立一个单独的web应用。在这个web应用对于订单的操作，并非传统意义基于数据库进行操作，而是调用低代码平台的操作API进行数据操作。也就是说用户下单之后就可以直接在低代码平台上的创建订单。如果未来开发手机端，也采取类似的操作。如果用户对商城的操作具有一些个性化的操作，这些记录都要单独保存，但是并不在后台统一数据模型（订单物料配送）中，那么就单独建立一个数据库，让自定义程序直接操作，或者也可以在低代码平台当中建立对应的数据模型。
在与企业ERP的操作，本质上是两个系统的数据交换，由于低代码平台和ERP之间的交换能力对不齐，这时候就需要一个中间商，左手去读取ERP的文本数据源，右手将数据通过API的方式更新到低代码的数据库当中。触发模式可以通过标准的调度来完成，根据业务需求每天同步一次 即可。
另一个场景是后台管理应用（也就是低代码）需要与现场的机柜设备所交互，同样是不具备这样的能力，仍然需要一个中间商。中间将机柜API调用，获取机柜实时状态数据，右手将数据传递给低代码平台的API。这里的触发，优先考虑通过低代码平台调用第三方服务api的模式来完成。
以上思路是将一个完整的程序，拆解成多个部分。围绕低代码平台进行数据建模，将后台常规功能利用低代码的高速开发能力，而客户端丰富的用户体验，则通过定制开发。数据交换则通过中间商来实现不同格式不同能力的转换。而定期的数据交换，则通过基础服务：用调度来支撑。实时数据交换，则采用低代码的调用第三方API方式来实现。
网友评论