模型介绍：在常规的 SaaS 系统中审核模块一般则重于资质的信息留存与相关安全的处理及审核状态的流转。资质信息以商户维度进行隔离，资质所需的内容通过字段进行预先定义。资质相关的业务开展围绕“资质信息详情表”来进行开展，相关的安全与审核强依赖具体的字段名，存在一定的硬编码。

优点：业务场景清晰，数据统计方便，模型和功能一目了然，开发难度低，理解简单，适合独立的业务场景。

缺点：不够灵活，不支持复杂业务场景，每多一个认证能力或者认证数据就需要新增表或者增加字段，复用性低，业务支持成本高，且扩展困难。

1.需要解决的问题

随着业务发展，资质的使用场景越来越丰富，原来面向单一场景（店铺资质）的能力已不满足基本诉求。

为了更好的适配多场景下资质的使用，减少增加使用场景所带来的开发成本，需要针对原先固定的资质模型进行改造，同时需要提供一定扩展性，实现功能的可插拔。

2.模型改造

以上为新模型的核心库表设计，在原有的基础上抽象出了场景模板配置，同时针对模板字段预设了多种类型策略，如：敏感字段加密、图片字段添加水印、风控接入等等。

当有更多的资质使用场景接入时，可按需进行模板定义，并根据实际业务需求进行模板字段的预设。资质中心的整体实现不与业务场景做强耦合，大大降低定制所带来的扩展局限性。

3.架构设计

4.设计实现

资质中心设计之初模型上就考虑支持业务上高扩展，能力上高可用，功能上可插拔，和 SaaS下多灵活的使用场景，总结就是高内聚、低耦合、明接口、通用性。

4.1 扩展性  

4.2 功能可插拔  

功能可插拔，通过在主表定义业务字段来实现不同功能的插拔，比如业务方的资质认证场景中主流程是要走多次审核，甚至部分审核流程不在资质中心，可以通过这些插拔字段动态接入，无需代码开发，接入成本小。

4.3 支持多场景  

微盟 SaaS 背景下不同应用的资质场景是不一样的，认证内容，认证标准，业务场景，这些不同业务方是不一样的，甚至同一个接入方也会改变，所以我们首先在支持数据维度上尽可能包含所有场景，同时把资质能力抽成独立模块通过定义的场景模版去表达使用哪些能力。

4.4 功能高可用  

将能力抽成单个小模块通过策略模式去定义和引用，既让能力可以独立扩张和重定义，也可以动态的去增加，对主流程无影响，能力间独立维护也确保不会快速腐化。

Factory 初始化相关能力资源，通过实现方法 executorAdopter 来定义资质流程中使用哪些能力，只需在场景模版中定义需要实现的能力，相关资质执行提交或查询过程中自动执行相关代码逻辑，做到高可用，可扩展。

4.5 资质维度泛化设计  

SaaS 场景下，资质对接的业务方业务场景跨度大，场景也是多变，在数据维度上，有的需要支持到商品级，有门店下还有的在店铺下，不同维度的诉求促使我们在资质维度上泛化。

1.资质模板配置界面化

目前资质的核心能力实现已完整，但面向运营的配置管理缺少界面化的交互应用，现阶段还是通过制定的 SOP 进行线下人工配置的方式来完成的。为了未来可以更友好的面向运营开放配置能力，同时为了减少线下人工对接所带来的风险与沟通成本，计划后续补充模板配置的运营管理后台。

2.增加审核规则

现下的审核规则单一：自动审核不通过则拦截资质的提交，人工审核不通过则拦截认证的状态翻转。

人工审核：运营人员根据提交的资质进行信息人工审核，根据结果进行状态翻转。

自动审核：三要素审核、人脸识别。

远期审核规则的展望：

 人工审核复杂化：人工的审核存在多级审核，如初审、复审等，或者存在多人联合审核等，且不同的资质场景对审核的诉求还各不一样。

自动审核差异化：不同的模板需要的自动审核内容存在差异。

为了可以动态适配此类诉求，针对审核抽象出规则配置，代码只需对规则进行策略实现，当资质模板进行配置时同步将审核规则进行差异化配置，无需做定制改造即可支持不同的场景不同的处理策略。

远期的业务架构图：

资质中心的设计和实现过程伴随着惊喜和艰难，在设计之初的模型构建和后续落地过程中出现部分情况边界定义不清晰，对于应用维度的资质使用欠缺走了些弯路。后续将更多的考虑相关通用能力的搭建，以及基于管理平台提供更便捷的场景模版定义，提高资质接入和维护的效率。