关于低代码的进一步思考

之前写过一篇低代码和无代码的文章，今天不知道该写啥，就重新思考了一下这个问题，水一篇文章凑个数。

对于很多业务，关注的一般是实体和流程。比如最常见的卖书这个案例，就会有商品(比如是书)、顾客、交易等实体。每个实体会有很多属性，比如书就会有标题、作者、价格、上市日期、库存量、锁定库存量等属性。特殊的实体会有生命周期，在生命周期转换的时候会有副作用。比如交易这个实体，在创建的时候会锁定书的库存量，在交易完成的时候会扣减库存。

在考虑低代码引擎的时候，就要考虑你的模型要与业务分离。比如商品这个实体，就是非常好做通用建模的，简单的五元组表就可以了（ className, classId, attrName, attrType, attrValue)。在很多能自定义字段的应用中我们能经常看到这种功能。

对于有生命周期的实体，就需要设计他的状态机，状态能否转换的检验，转换时的副作用。这块应该需要引入一个合适的脚本语言来驱动（比如 groovy 等)。这个引擎有点难度，但也是可以搞定的。

理论上有这两个引擎，这个服务应该就可以跑起来了。但实际的商业模式可能会更复杂，比如一个简单的例子，老板决策，除了 180 天内的新书，剩下的所有书籍打九折。

这个事情有两个解法，一个解法是每天派一个员工，去发现哪些书超过了 180 天，全部调整为 9 折。这个解法有一个对应的软件技术就是 RPA，写一个 RPA，每天定点启动，去干好这件事情。另外一个解法就是在商品获取售价属性这个上面挂钩子，绑定到一个上层策略，这个上层策略用一个脚本语言来驱动。似乎这个也是能搞定的。

所以最后就变成了引擎层（实体支持，状态机支持，钩子支持），业务层（给出商品、顾客、交易等概念的模型，完成交易的状态机转换脚本），决策层（实现灵活的业务决策，各种钩子和开关）。

其中引擎层用 Java、Golang 实现就挺好；业务层最好有一个领域语言，从降低开发人员需求角度来看，这个领域语言最好还是可以可视化编辑的，还要有一个脚本语言来支持状态机转换；决策层的思路跟状态机部分类似，只是多了一个钩子定义。当然状态机转换本身就是一种钩子，只不过状态机转换太常用，逻辑又太多，最好分开好一点。