规则校验功能设计思路

一、需求描述

1. 每个表单参与校验的字段几十个，整个系统参与校验的字段数以百计，此时采用传统的前后端校验方式会使前端逻辑复杂度陡然增加，后端接口亦然，灵活性也不高。
2. 系统需要对数据录入质量做记录，方便统计和考核。
3. 规则可能随政策变化，必须支持以配置的方式来管理和维护，可能还需要导入，纯配置文件的方式对用户不友好，所以规则必须采用数据库持久化。
4. RuleEngine（Drools、mvel2）、RDBMS（MySQL）、DistributedCache（Redis）。

二、概要设计

1. 构建功能模块树（可以限定为二至三级），方便按功能模块管理、加载规则、校验结果记录。

• 法一、可以放在一张表中，增加type和parent_id字段，标记式模块还是功能点。

id
key
type
parent_id

• 法二、可以将模块key放到公共字典表中，本表只存功能点key。

id
module_key
function_key

2. 所有规则项都应依据模块key来组织，方便细化缓存粒度，方便创建索引以加快规则查询速度。

id
module_key
input_key
rule_value

3. 规则匹配过程

• 前端
  • 可以通过约定好的模块key查询模块树，加载对应的规则列表。
  • 在输入处利用约定的rule_key从规则列表读取一条规则。
  • 发起异步校验请求，携带参数为：rule_value、input_value、module_key。
• 后端
  • 执行校验
  • 将结果异步入库
  • 返回结果给

三、疑点：

1. 校验结果记录的粒度？若记录到订单，新增时订单id在何时生成，此时若没有订单id怎么办。若记录到模块或个人，如何细分。
2. 针对同一条业务属性的校验结果，面对编辑操作，是记录流水还是覆盖存储？
3. 前后端对module_key、rule_key的获取，采用约定式还是加载式？大概率要采用约定式，即采用硬编码的方式。
4. 是否需要做成微服务？至少独立成功能模块。
5. 以整个表单为单位集中校验还是逐个字段校验？

四、附录

mvel语法实例：https://www.cnblogs.com/cg14/p/11870882.html
https://blog.csdn.net/SunnyYoona/article/details/75244442