对于动态注入业务逻辑，方便用户自定义逻辑的扩展，我这里并不过多考虑，经过多年的实践，个人觉得，低代码设计的再复杂，也无法满足客户50%以上的需求，比如我做了一个最简单行业（洗涤行业）下单界面，界面不是太复杂，但是通过拖拽方式比较难生成，这不是最核心的，最核心的是下单后：
1）支付方式：卡支付，现金（现钞，支付宝，微信，银行卡，分别会调用不同第三方），核销支付，不同支付方式无论是前端还是后端，差异比较大，况且前端还有是否保价，代为保管（收钱），不同客户下单折扣不同等业务逻辑
2）下单后，客户卡余额减少（卡支付的话），或者核销第三方，例如美团优惠券（核销支付）
3）下单后发送短信
4）下单后，微信公众号推送消息
5） 下单后有可能触发快递
6）客户积分增加
7）风险启动（一个卡当天多次下单，判断为异常）
8）下单后生成各种日志（资金变动日志，单据状态变动日志等等）
这些根本不可能通过任何所谓的复杂界面，各类灵活接口配置出来，所以个人认为，低代码只需要做好简单的40%的场景就好了，剩下30%是行业背景的低代码化，比如我刚才说的场景，剩余30%需要程序员参与，低代码产品本身的复杂化，无论是UI还是代码注入，都没任何意义。
基于以上的价值观，所以，我决定实现一个简单通用的低代码开发平台，不需要业务逻辑的注入，只需要实现单表的增删改查即可，并在此基础上，根据不同行业，个性化自己的业务逻辑。比如以上8个步骤，代码稳定后，就可以作为洗涤行业低代码开发注入，从而由40%基础低代码开发平台，迈向70%行业定制化低代码开发平台
| 留言与评论（共有 0 条评论） “” |
