近来在公司领到一个小需求，需求对之前已有的试用用户请求规矩进行拓宽。咱们的场景大约如下所示：
依照上述的条件咱们可以得出的结论是：
- 咱们的主要流程主要是基于 and 或许 or 的联系。
- 假如有一个不匹配的话，其实咱们后续的流程是不用执行的，就是需求具有一个短路的功用。
- 关于现在的现状来说，我假如在原有的根底上来改，只需稍微留心一下处理需求不是很大的问题，可是说后边可维护性十分差。
后边通过权衡往后，我仍是决定将这个部分进行重构一下。
规矩执行器
针对这个需求，我首要梳理了一下咱们规矩执行器大约的规划， 然后我规划了一个 V1 版别和咱们一起同享一下，假如咱们也有这样的case 可以给我同享留言，下面部分主要是规划和完成的流程和 code.
规矩执行器的规划
关于规矩的笼统并完成规矩
执行器构建
执行器的调用
总结
规矩执行器的利益和缺陷
利益：
- 比较简单，每个规矩可以独立，将规矩，数据，执行器拆分出来，调用方比较规整；
- 我在 Rule 模板类中界说 convert 办法做参数的转化这样可以可以，为特定 rule 需求的场景数据供应拓宽。
缺陷：
- 上下 rule 有数据依赖性，假如直接修正公共传输政策 dto这样规划不是很合理，主张提前构建数据。
