业务系统知识沉淀的思考与初步探索

系统文档是当前对业务系统知识进行沉淀的主要手段。由于业务系统快速迭代或者人员的流动，文档缺失、风格各异、没有与迭代同步更新等问题十分常见，文档质量也是因人而异。,随之而来的是研发效率、产研协作效率、质量等一系列的问题，在团队人员流动频繁的情况下尤为突出。,图片,图为研发流程示意图，绿色箭头部分是理想、高效的流程；但是由于不同角色间的信息差异，某一知识若不能从知识库中获取，就会存在红色箭头部分的逆向流程，需要各角色来回沟通确认；这样的知识越多，逆向流程越多，研发流程越长，效率越低,去年，我们使用领域驱动设计（Domain-Driven Design，DDD）的思想对系统进行了重构。在DDD中，以统一语言为基础，面向业务进行领域建模，将真实业务与软件实现关联起来，以领域模型为知识的载体实现沉淀。但是到最终的落地实现，知识沉淀的手段还是落到文档上。,我们希望找到一种通用的知识沉淀方法，自动从代码中抽象、提炼业务知识，以及展现和沉淀知识，达到“代码即文档”的效果。,图片,原始代码中蕴含了我们需要的知识，但非结构化、无统一规律的代码难以直接转换为知识；需要一层中间的抽象来规范化结构化原始代码，从有既定规律的代码中就可提炼出我们所需的知识,商品的价格尾数必须是“8”是业务系统知识，商品上架后会发出MQ通知也是业务系统知识。根据侧重的不同分2个方向：,无论是业务规则还是技术实现无外乎什么条件下做什么事情，知识就在各种流程控制逻辑中。比如，各种业务规则判断、根据不同条件页面展示不同内容、监听某个消息进行业务处理、通过策略模式进行逻辑分发等，都可以认为是流程控制的不同实现，通俗理解就是对IF-ELSE逻辑的各种不同实现。,与DDD中面向业务进行建模不同，既然知识存在于流程控制逻辑中，那就对流程控制进行抽象、建模；脱离于具体的业务场景才能通用于每一种业务场景。,我们将流程控制的抽象定义为广义的设计模式，是对IF-ELSE逻辑不同实现方式的抽象，包括常见的设计模式如责任链模式、策略模式、以及后文涉及的状态机（FSM）、以及后续需要针对性的进行自定义抽象。业务系统知识就被承载其中，而且是结构化的、方便被提取的。,业务系统中使用了一套拓展状态机（FSM-X）的框架，符合上述对流程控制进行抽象、建模的想法，也是一种对IF-ELSE逻辑的实现方式。所以我们将FSM-X的可视化作为业务系统知识沉淀的初步探索。,FSM-X核心还是有限状态机（FSM）的实现，然后在此基础上扩展集成了事务消息、JOB等功能；相关的配置项统一存储到数据库中，方便配置和管理。主要有以下几个核心概念：,系统整体实现架构如下图,图片,与FSM-X中的几种核心组件对应，可视化的视图节点主要有以下几种：,图片,上图为“SUPPLY_PRODUCT”域“质检合格”后“上架”事件节点，最后流转到“预上架”状态，之后有21条可能的链继续往后流转。,图片,上图红框中为2条状态机链，表示“SUPPLY_PRODUCT”域“上架”操作完成后可能执行“PRODUCT_MART”域“预上架”操作，也可能执行“SUPPLY_PRODUCT”域“上架取消（无可上架卖场）”操作。具体会怎么执行，由链中的业务逻辑控制，目前这部分还没有可视化，需要由其他自定义的广义设计模式来进行抽象。,图片,图片,以我们系统中商品的上架流程为例，比较完整的可视化效果图如下,图片,从图中可以看出上架流程的整体执行过程，但还只是一个粗粒度的框架；因为单一从FSM-X中提炼出来的业务系统知识是有限的，更多的知识还存在于无法被抽象提炼的非结构化代码中。,我们把FSM-X这一套业务框架理解为对一类流程控制逻辑的抽象，是前文中提到的广义设计模式的一种。于是进行了FSM-X的可视化实现，作为用广义设计模式去抽象和承载业务知识，完成提取和沉淀这种思路的探索实践。,从目前的结果看，可视化的流程图能够表达状态机流转相关的业务知识，只是知识的完整性还远远不够，毕竟目前只是从一种广义设计模式提取了知识，大部分的业务知识是不被包含在内的。但是通过这个效果，笔者认为这种思路是可以继续探索的，对流程控制的各种实现都做好抽象之后，相当于形成了一套详细的代码规范，在既定规范内的业务代码就能实现业务知识的抽取、沉淀。敬请期待!!!,王轮，转转B2C技术部后端研发工程师