产品模型设计与应用以及思考

产品模型

一、旧产品模型

  原有旧产品模型，采用key-value的简单模式，将所有的产品参数定义在了value之中，以定长的方式处理

  其中的劣势有以下几点：

• value中保留值过于冗余，每个产品即使没有对应的参数，也需要空出对应的位置保存数据；
• 由于定长的原因，如果存在列表形式的数据，需要添加字段或者变更字段长度会导致旧数据无法兼容，导致扩展性差；
• 对于问题排查，需要解析某一个参数值，比较难以准确定位；

二、新产品模型设计

2.1宽表和高表的选择

  产品模型的设计，有采用宽表的设计，也有采用高表的设计，而不同的设计，衍生出来的设计、查询、检查之类的优劣性如下：

  宽表的优势

• 查询速度快

• 对于关联字段修改无需变更多张表数据

  宽表的劣势

• 很多的冗余字段

• 对于不再使用的字段或者新增字段，需要变更表结构处理

  高表的优势

• 新增产品参数不需要表结构变更

• 无需冗余保存无用字段

  高表的劣势

• 如果要修改关联字段，比如产品代码，则所有的表都要进行变更

• 查询一个产品的数据，要将几个关联表的数据都查询出来，耗时相较于宽表的处理要更久一点

• 表修改处理要添加逻辑判断需要修改哪些表哪些字段

2.2新产品模型设计

  根据产品的分析，将产品划分为几个维度的表结构数据：

  产品分析：

• 产品有分为单个产品发售的，也有按期发售的产品；
• 产品事件上存在签约、开户、存入、支取、计息等相关操作；
• 单个产品或者单期产品，存在不同的币种类型；
• 产品基础通用信息；

  基于以上的表结构设计：

• 基础数据信息，产品中英文，产品码，版本号等基础数据；
• 关联产品表，存储子产品与可售基础产品的关联关系；
• 产品参数表，存储各相关基础参数；
• 产品事件表，存储各相关事件下的产品参数，例如开户事件下指标参数；
• 产品矩阵表，存储产品中存在多参数下的参数矩阵数据，例如货币矩阵；

三、产品校验模式的优劣以及优化思路

  对于银行系统来说，大多数的业务逻辑大差不差，主要的差异化在于产品一些指标的定义。在各类事件下，一般需要对大量的产品指标做校验，如果对于每个产品指标都做一套硬编码形式的校验，那明显不合适，存在冗余代码。且对于某些产品新增的指标校验，可能在后续使用中也会应用到其他产品中去，所以也需要考虑相关指标校验代码的复用性，另外，存在着后续可能有某些指标需要作废的处理。

  根据现行的业务情况，产品的配置在业务上不会经常发生，除了按期发布的产品，所以产品参数相当适合进行缓存处理。依据现存的情况，以及产品模型设计，产品表结构设计，现行的产品校验模式为，在产品事件表、产品矩阵表中定义一系列的事件以及指标，通过spring的bean管理机制，定义一个基础的产品指标校验接口，接口入参包括产品缓存对象以及上下文对象，通过各个校验的实现类实现各指标校验逻辑，并且通过别名方式交由spring的context管理，在各类事件下，将需要校验的相关参数传入上下文对象中，通过缓存读取当前事件下的所有指标，指标在数据库中的配置与各个bean的别名保持一致，循环从context中获取到对应的bean进行检查。

  该产品校验模式的优势：

• 产品指标校验的代码可以进行复用，不同产品间的复用，不同事件的复用；

• 某个产品或者事件新增指标可能只需要进行简单的上下文传值，以及数据库新增配置，如果原先相关参数已经在上下文中，则只需要对数据库进行变更，以及产品crud进行修改调整即可；

• 对于废弃的指标，可以直接删除对于的指标数据，即可做到不对该指标进行检查，这个对于硬编码形式的处理更加灵活；

• 废弃的指标即使不删除代码也不会对流程造成影响；

• 通过指标bean另外将校验逻辑暴露，可以保证其他非事件下的校验也能复用代码；

  该产品校验模式的劣势：

• 无法对复杂的逻辑进行处理，例如：或逻辑的处理、多个且组合，不同组间或的逻辑处理、且或开关处理等；

• 指标校验类过多，且比较分散，没有统一的管理细则；

• 由于不同领域的指标由不同领域各自实现，对于新增、修改产品指标逻辑需要多方协调；

  优化思路：

• 对于复杂指标引入规则引擎，或者简单处理将多个或逻辑事件抽取为一个组或者事件，进行或的逻辑处理；

• 指标校验进行统一的管理；

四、扩展应用以及思考

  对于产品中心的设计，优缺点的思考后，反看自己负责的支取主逻辑，存在极大的相似之处。先将支取的主流程拆分为：初始化获取基础数据信息，根据获取到的基础信息进行不同维度的校验，对于业务上的逻辑处理，输出信息。由此可分为init、check、handle。原先对于主流程的处理相对来说比较流程化以及硬编码的形式，也有人吐槽过我的init方法中冗余太多的处理逻辑，许多交易其实不需要那么多的处理逻辑。参考产品中心的设计，其实支取主逻辑可以抽象为一个接口，入参为上下文对象，另外一个为产品化方法处理对象。以初始化接口为例，其实可以通过不同的凭证对于各个实现类进行命名，例如：卡类型的凭证需要获取哪些基础信息，例如卡信息，卡客户信息，卡账关联信息等，命名上可以用card+业务+init或者其他别名命名规则，处理顺序可以通过order进行排序，后续代码的处理大多在于服务实现的编排以及新增业务的开发。

  优势：

• 实现业务代码和产品检查一样的优势：代码复用、数据库编排控制代码处理流程

• 对于有问题的业务实现，可以通过编排的处理对业务进行下线

  劣势：

• 会拆分出来很多的实现类

• 对于不熟悉的人来说阅读代码需要一些时间

• 不同实现类的排序依赖性较强

  产品中心的实践和应用，我觉得这无疑是在抽取公共方法，抽象业务实现中值得去参考和学习的。