![[程序员日记]---从业务编排到低代码](/static/background/93.jpg "[程序员日记]---从业务编排到低代码")
低代码这个词也是最近这几年很火的概念，尤其是遇到大环境下行，很多大厂和互联网那个公司也在慢慢在低代码方向发力，当然，对于传统项目交付型的软件公司，低代码也具有相当大的吸引力。
如何理解低代码
如果基于这个思路，是不是大家觉得有一些类比？
命令式 vs 描述式
对于传统的软件开发，我们需要定义数据结构，定义变量，通过一行行命令式的代码，来精准的控制计算机执行每一步操作。这个过程中，对于开发者要求是比较高的，要有计算机运行的基本知识，要有算法的基本能力，而且时常要从计算机角度触发逻辑思考，包括线程池管理，内存管理等问题。这些，无疑都增加了开发者的门槛，同时也会增加工作量。
所谓描述式的编程，就是把业务需求标准化，配置化，最优方案是可视化的配置的方式实现快速开发，这个过程中，开发人员不用关心计算机底层逻辑，只需要描述好数据模型，业务流程即可。
说一下我们熟悉的一些业务场景，包括 工作流引擎，前端页面装修等，这些业务场景已经有了很成熟的低代码框架帮我们解决。比如工作流引擎，当你处理流程审批的业务场景的时候，如果没有工作流引擎，你可能还需要自己用状态机来硬编码你的程序，有了工作流引擎，我们可以实现业务配置化。
低代码实现路径---业务编排
业务编排思想核心还是业务单元模块化，这个在某种程度跟微服务思想有点不谋而合。通过模块化去解耦复杂业务系统，化繁为简。下面贴一个简单的业务编排架构图：
1. 核心组件说明
a. 流程引擎，规则引擎和决策表。
b. 上下文管理。
这个也是很重要的，在一个复杂的业务编排过程中，每个独立组件之间不可避免会有数据交互，而这些都交给了上下文处理。对于上下文管理，也有两种方式，一种是流程串联中的上下文传输，类似水流中的小纸船，他会在流程中通过业务控制实现上下文的传递，当然这种在实现和理解上都会更复杂一些。
2. 案例讲解
这里举个业务编排的例子，我们以商品详情查看为例：
你可以将瀑布流式的代码，转变成以组件为核心概念的代码结构，这种结构的好处是可以任意编排，组件与组件之间是解耦的，组件可以用脚本来定义，组件之间的流转全靠规则来驱动。
上面的案例是笔者在采灵通系统开发中真实的一个案例，笔者最开始是采用瀑布方式实现的该搜索关键字处理逻辑。但之后进行了重构，通过引入开源框架liteFlow的业务编排框架，极大的简化的业务复杂度。基本可以实现流程图即代码的程度。具体代码就不贴在此处了，如果大家该兴趣，可以去研究一下liteflow这个业务编排开源框架。
从业务编排晋升为低代码框架
总结
业务编排是实现低代码的路径之一，但不是唯一路径。尤其是当我看到ChartGPT4.0出来之后，人工智能，可以通过一个网页草图自动生成html代码时，我觉得，这可能才是低代码的最终归宿吧。
内容来源：京东云开发者社区