您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件开发专栏 > 开发技术 > 正文

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

发表于:2023-06-28 作者:王轮 来源:转转技术

1 背景介绍

1.1 要解决什么问题

系统文档是当前对业务系统知识进行沉淀的主要手段。由于业务系统快速迭代或者人员的流动,文档缺失、风格各异、没有与迭代同步更新等问题十分常见,文档质量也是因人而异。

随之而来的是研发效率、产研协作效率、质量等一系列的问题,在团队人员流动频繁的情况下尤为突出。

图片图片

图为研发流程示意图,绿色箭头部分是理想、高效的流程;但是由于不同角色间的信息差异,某一知识若不能从知识库中获取,就会存在红色箭头部分的逆向流程,需要各角色来回沟通确认;这样的知识越多,逆向流程越多,研发流程越长,效率越低

1.2 业务系统背景

去年,我们使用领域驱动设计(Domain-Driven Design,DDD)的思想对系统进行了重构。在DDD中,以统一语言为基础,面向业务进行领域建模,将真实业务与软件实现关联起来,以领域模型为知识的载体实现沉淀。但是到最终的落地实现,知识沉淀的手段还是落到文档上。

我们希望找到一种通用的知识沉淀方法,自动从代码中抽象、提炼业务知识,以及展现和沉淀知识,达到“代码即文档”的效果。

2 我们的思考

图片图片

原始代码中蕴含了我们需要的知识,但非结构化、无统一规律的代码难以直接转换为知识;需要一层中间的抽象来规范化结构化原始代码,从有既定规律的代码中就可提炼出我们所需的知识

2.1 什么是业务系统知识

商品的价格尾数必须是“8”是业务系统知识,商品上架后会发出MQ通知也是业务系统知识。根据侧重的不同分2个方向:

  • 纯粹的业务知识,仅仅是业务规则的体现,与技术实现无关;
  • 系统知识,可能包含了业务的规则,更重要的是技术实现方案的体现;比如为了保证数据的最终一致性,系统的实现往往比直接的业务规则要复杂。

2.2 知识存在于哪里

无论是业务规则还是技术实现无外乎什么条件下做什么事情,知识就在各种流程控制逻辑中。比如,各种业务规则判断、根据不同条件页面展示不同内容、监听某个消息进行业务处理、通过策略模式进行逻辑分发等,都可以认为是流程控制的不同实现,通俗理解就是对IF-ELSE逻辑的各种不同实现。

2.3 如何提炼出业务系统知识

与DDD中面向业务进行建模不同,既然知识存在于流程控制逻辑中,那就对流程控制进行抽象、建模;脱离于具体的业务场景才能通用于每一种业务场景。

我们将流程控制的抽象定义为广义的设计模式,是对IF-ELSE逻辑不同实现方式的抽象,包括常见的设计模式如责任链模式、策略模式、以及后文涉及的状态机(FSM)、以及后续需要针对性的进行自定义抽象。业务系统知识就被承载其中,而且是结构化的、方便被提取的。

3 探索性实践

业务系统中使用了一套拓展状态机(FSM-X)的框架,符合上述对流程控制进行抽象、建模的想法,也是一种对IF-ELSE逻辑的实现方式。所以我们将FSM-X的可视化作为业务系统知识沉淀的初步探索。

3.1 FSM-X

FSM-X核心还是有限状态机(FSM)的实现,然后在此基础上扩展集成了事务消息、JOB等功能;相关的配置项统一存储到数据库中,方便配置和管理。主要有以下几个核心概念:

  • Mapping:可以认为是FSM中的变换(Transition),包含了源状态、目标状态、事件、操作,表示在源状态下发生某一事件,触发对应的操作,流转到目标状态。还包含了JOB、事务消息(TxMsg)、状态机链(Chain)。
  • Chain:状态机链,用于链接2个Mapping,当前的Mapping的流转完成后自动执行链后的Mapping流转。
  • JOB:异步任务,当Mapping中配置了JOB时,会自动执行对应的JOB。
  • TxMsg:事务消息,如果Mapping中有对应配置,完成Mapping流转的同时自动发送消息。

3.2 FSM-X可视化实现

系统整体实现架构如下图

图片图片

  • FSMX配置中心统一管理所有配置,对外提供拉取配置数据的能力。
  • FSMX客户端在业务服务启动时拉取配置完成启动,然后异步对状态机数据进行转换,得到可视化数据并进行上报。
  • FSMX配置中心会在本地缓存可视化数据,并对其进行加工对外呈现。

与FSM-X中的几种核心组件对应,可视化的视图节点主要有以下几种:

  • Mapping

图片图片

上图为“SUPPLY_PRODUCT”域“质检合格”后“上架”事件节点,最后流转到“预上架”状态,之后有21条可能的链继续往后流转。

  • Chain

图片图片

上图红框中为2条状态机链,表示“SUPPLY_PRODUCT”域“上架”操作完成后可能执行“PRODUCT_MART”域“预上架”操作,也可能执行“SUPPLY_PRODUCT”域“上架取消(无可上架卖场)”操作。具体会怎么执行,由链中的业务逻辑控制,目前这部分还没有可视化,需要由其他自定义的广义设计模式来进行抽象。

  • JOB

图片图片

  • MSG

图片图片

以我们系统中商品的上架流程为例,比较完整的可视化效果图如下

图片图片

从图中可以看出上架流程的整体执行过程,但还只是一个粗粒度的框架;因为单一从FSM-X中提炼出来的业务系统知识是有限的,更多的知识还存在于无法被抽象提炼的非结构化代码中。

4 总结

我们把FSM-X这一套业务框架理解为对一类流程控制逻辑的抽象,是前文中提到的广义设计模式的一种。于是进行了FSM-X的可视化实现,作为用广义设计模式去抽象和承载业务知识,完成提取和沉淀这种思路的探索实践。

从目前的结果看,可视化的流程图能够表达状态机流转相关的业务知识,只是知识的完整性还远远不够,毕竟目前只是从一种广义设计模式提取了知识,大部分的业务知识是不被包含在内的。但是通过这个效果,笔者认为这种思路是可以继续探索的,对流程控制的各种实现都做好抽象之后,相当于形成了一套详细的代码规范,在既定规范内的业务代码就能实现业务知识的抽取、沉淀。敬请期待!!!

关于作者

王轮,转转B2C技术部后端研发工程师