讲解地址 暂定不知道在哪
极简流程引擎框架【配置化,节点话,原子化,自闭环处理】 【有思路的我三天就可以一顿爆写哈哈】
- 了解抽象,反射,继承,实现,bean注入 等写框架的基本知识
- 去看下QL-express的基本用法
- 了解spring-bean查找的基本原理
- 熟悉框架流程原子能力
- 了解项目统一异常机制
- testRunFlowA_have_companyName
- testRunFlowB_No_companyName 具体原理看返回结果
如果没有“DeadLine”最后期限的概念,那么程序员的世界将一片平和。我们将会有足够的的时间去进行one piece (对待问题的最佳的设计和解决方案),peace & love !
-
在有限的时间内,如果寻找框架和需求等架构设计的最佳平衡点是一个长久不衰的问题,至今在世界上仍然派系林立!
-
暴力搜哈派 - 不要和我说架构,不要和我说设计,我这人习惯就是边敲边干,边干边设计,我的眼睛就是尺,还不如直接敲
-
借鉴派 - 看看类似的有木有成熟的经验借鉴,按照正常的标准来就可以了
-
全量文档派 - 不用谈什么设计,我有文档,我文档写的好即使设计的有偏差也不会出错
-
灵活派 - 看情况,根据实际的项目需求灵活排期,灵活设计
之前业内有证明了随着架构设计时间的增加,开发和返工量都会减少,所以在这有限时间内,找到一个最佳平衡点来进行设计是一个问题,那么如何来找到最佳平衡点,让我们少走弯路,既能够灵活设计,又能够按时上线,又能够符合当下现状和需求成本了本次文章探讨的命题,本文将从复杂机审流程进行举例,来看下踩了哪些坑,又做对了哪些事情,最后终于在架构【需求+设计+时间】 = 设计平衡点!也就是本次框架设计的初衷!
入驻机审流程从当前的业务与系统角度看存在如下几个问题
- 流程复杂 业务耦合严重
往往牵一发动全身【同商,同人,火眼风险等等,统一在一个流程里面进行校验】迭代成本高【举例有一些特殊供应商可能,只要部分能力,无需其他能力】
- 稳定性差 测试成本高 那么如果有迭代需求,业务上必须非常熟悉每一个流程细节,因为都是耦合在一起的,技术上必须要改动多个点,没法已单个原子粒度拆分来进行开发与测试,如果有一些特殊的部分能力需要的供应商,就会导致技术侧流程愈发耦合严重,理解成本越来越高。 因此,为了快速实现功能迭代,与千人千面的需求,亟需在架构上进行优化升级,技术赋能业务!
所以需要几个能力
- 业务上拆解原子粒度能力
- 一个轻量级的配置流程中心【可将单点原子能力聚合,重组】的扩展引擎来进行数据业务,技术解耦,快速迭代
- 简单便捷、轻量级的配置能力,易于上手。
- 低代码设计,组件化封装。
- 流程编排,快速支持多场景迭代。
- 抽出业务原子能力,进行数据解耦与迭代,能够支撑复杂机审流程入驻链路整体拆解能力
- 符合业务要求,可承接流程原子
- 处理各节点闭环结果表达式
- 处理最终结果表达式
- 可扩展可各类型流程
- 原子能力可复用
- 流程配置化
- 具备重试&持久化&回放能力
- 轻量级引擎,用起来爽方便快捷