多场景的业务建模系统

多场景的业务建模系统

背景

在介绍整套方案之前，一定先要介绍ED目前是从事的是互联网金融开发，因为我们的整套方案设计，确实跟行业属性有密切的关系，这套方案大概已经积累了1年多了，在日常开发过程中我们的业务有如下特点：

?首先每个月几乎都有新场景的开发工作

?新场景中有60%的需求是一样的，也有40%是不太一样的

?我们的产品大致分为申请、激活、放款、还款4大流程，每个流程都是给不同的后端提供数据核心问题如下，一切皆是差异化：

?交互视觉的差异化：每个场景在设计上总是一些不太相同的地方

?产品流程的差异化：PM有时候会在某些页面上添加一些额外的展示位

?风险控制的差异化：这里多阐述下，金融放贷的核心就是风控，做过金融开发的同学肯定知道，每个场景需要收集用户哪些信息，都是由风控来决定的，对于FE最后表现出来的就是视觉和交互上的差异，对于PHP就是每个场景收集字段的差异，这也是我们整套设计方案重点之一?第三方机构的差异化：每个机构输出的信息不一致，由于技术体系不在FE的范畴，本文不介绍我们的目的：提升开发效率的同时提升我们金融产品管理能力

整体架构设计

这个背景颜色的目前都是FE的工作（实在不知道这个颜色怎么描述）

?首要的前提就是公司目前在Node框架、线上运维、机房容灾等这块支持非常好

?FE能更熟悉业务，更好的优化业务：其实很多B端相关的配置工作其实都是FE自己的，但是却需要PHP在后端支持下，这块不管事对PHP还是FE都非常的不好

?节省整体的人力：对于一个新场景的开发，原来需要1FE+1PHP，现在只需要1FE+0.5PHP ?减少FE和PHP的沟通成本：原来因为相互耦合更重，自然沟通成本更高，现在有了公共服务，相当于依赖更加松散了，沟通成本自然会下降

我们创新的几个核心关键点：

我们将一个新场景的工作分成了公共业务和场景业务，公共业务统一都由FMS来处理，对于个性化的业务都由不同的SCENE来处理

FMS

FMS模块里面包含了所有的公共业务，其中有几个关键点：

?多版本控制：这样可以保证公共业务的上线修改，不需要所有场景都统一回归

?基于配置生成页面，一切差异化都体现在配置里面（讲B端的时候会展示配置的可视化页面）o组件化：对于表单填写类的页面，我们都是组件化配置生成页面，这样可以更加灵活

o模块化：对于业务需求比较标准的页面，我们就以模块化配置生成页面，这样更加方便可视化配置，比如富文本编辑类似的配置，这个最好还是模块化生成

AXE

Axe是我们积累下来的公共方法：包括了passport处理、工具方法、action基类、RPC请求封装、统一的错误码定义、mock数据等。