一、需求描述
- 每个表单参与校验的字段几十个，整个系统参与校验的字段数以百计，此时采用传统的前后端校验方式会使前端逻辑复杂度陡然增加，后端接口亦然，灵活性也不高。
- 系统需要对数据录入质量做记录，方便统计和考核。
- 规则可能随政策变化，必须支持以配置的方式来管理和维护，
可能还需要导入，纯配置文件的方式对用户不友好，所以规则必须采用数据库持久化。 - RuleEngine（Drools、mvel2）、RDBMS（MySQL）、DistributedCache（Redis）。
二、概要设计
- 构建功能模块树（可以限定为二至三级），方便按功能模块管理、加载规则、校验结果记录。
- 法一、可以放在一张表中，增加type和parent_id字段，标记式模块还是功能点。
id
key
type
parent_id
- 法二、可以将模块key放到公共字典表中，本表只存功能点key。
id
module_key
function_key
- 所有规则项都应依据模块key来组织，方便细化缓存粒度，方便创建索引以加快规则查询速度。
id
module_key
input_key
rule_value
- 规则匹配过程
- 前端
- 可以通过约定好的模块key查询模块树，加载对应的规则列表。
- 在输入处利用约定的rule_key从规则列表读取一条规则。
- 发起异步校验请求，携带参数为：rule_value、input_value、module_key。
- 后端
- 执行校验
- 将结果异步入库
- 返回结果给
三、疑点：
- 校验结果记录的粒度？若记录到订单，新增时订单id在何时生成，此时若没有订单id怎么办。若记录到模块或个人，如何细分。
- 针对同一条业务属性的校验结果，面对编辑操作，是记录流水还是覆盖存储？
- 前后端对module_key、rule_key的获取，采用约定式还是加载式？大概率要采用约定式，即采用硬编码的方式。
- 是否需要做成微服务？至少独立成功能模块。
- 以整个表单为单位集中校验还是逐个字段校验？
四、附录
mvel语法实例：https://www.cnblogs.com/cg14/p/11870882.html
https://blog.csdn.net/SunnyYoona/article/details/75244442