在数学中，矩阵（Matrix）是一个按照长方阵列排列的复数或实数集合。

有限的因变量与自由发挥的自变量

先设定一下业务场景，假设我们要做电话套餐系统。

一个电话套餐里直接影响客户使用体验的是：

• 价格

• 通话

• • 每月免费接听时长

  • 每分钟接听收费

  • 每月免费拨打时长

  • 每分钟拨号收费

• 短信

• • 每月免费条数

  • 每条收费金额

• 流量

• • 是否降速无限流量

  • 流量包购买价格

  • 套餐内包含流量

本文称呼上述的内容是一个套餐系统中的因变量，是最终结果，其值由多个自变量联合确定。电话套餐的因变量可能不止于这些内容，但其总是有限可枚举的。

对应的，本文将以下内容称为 自变量：

• 地域（这个无限流量的套餐只能给广东省客户的）

• 身份（看在他还在读书的份上，套餐费用给他减几块钱吧）

• 公司（这个是合作公司，整个公司都用我们的短号，这个套餐必须要优惠点）

• 客户画像（这货看起来很有钱，对他展示一些高价套餐，同时象征性给他多一点通话时长吧）

• 营销入口（这个从我们的活动链接进来薅羊毛的，还是给他减点价吧）

• 使用的客户端（最近在推广APP,在APP申请的套餐给他送点流量吧）

• 基础套餐定义（这个套餐叫 无线流量卡，客户申请这个套餐时，我们给他一个基准内容吧）

• ......

导致因变量变化的自变量很多，同时多个自变量也有可能联合使用触发新规则：

• 地域为广东地区身份为学生的客户购买套餐时 额外送1G

• 公司为 X 的 领导岗位 免话费

• ......

相对于因变量，自变量及其组合的数量可能难以想象的庞大。

如果每个自变量的组合等情况都要在我们的系统中通过代码来定义，这是一个难以想象的灾难。

此时此刻产品、渠道等自变量究竟是什么

一个人，在公司里是员工，在父母前是儿子，在老婆前是丈夫，在车里他是司机。

人是多面的，在每个不同的场景有不同的表现，并且在特定的场景也只需要有特定的表现，而不能串场。

我们业务系统里的渠道可能是 APP,小程序，H5,桌面应用等，这些渠道自身有很多其他的特性，但在套餐系统关心的渠道仅仅是：

• 当渠道为APP时，额外赠送1G流量，减免5块钱

• 当渠道为小程序时，送100M流量

• ......

这些对套餐的影响，定义了在 套餐场景下，一个渠道是什么。

同理，我们依然可以通过同样的形式，定义套餐系统里 地域的含义，身份的含义，营销入口的含义，这与NLP中的词向量有异曲同工之妙。

通过自变量确定因变量

要通过自变量（外部套餐，渠道，营销入口等）计算出因变量（最终面向客户的套餐内容），首先要确定的是 计算规则。

一个可供的参考的形式如下：

• 为每个自变量类型确定整体的执行优先级

• 为每个因变量类型确定计算的形式

如上一节的表格中，我们可以定义各类自变量计算优先级：

• 基础套餐定义 低

• 渠道 中

• 营销入口 高

那么 合作公司A引流的客户在App中 选择了 流量霸王套餐 ，那么它的流量是

5G + 1G + 1G = 7G

上面的规则很简单，就是简单的加减操作

而赠送彩铃可以选择另外的规则，只要出现过“是”，那就“是”

否 + 是 + 否 = 是

多自变量联合确定的操作内容的场景

如果出现了

“当 营销入口为 A 公司 渠道用的是 APP时，
给我再额外送2G流量”

又或者

“我不管你什么设计，我的这个套餐就是不允许
其他乱七八糟的 渠道、营销入口修改内容”

等需求时，就会打破上述简单的按照单个自变量优先级排序的规则

我们可以额外新增一个更高优先级的自变量，以实现特定的需求

这样我们就可以解决业务的特殊需求。

优缺点分析

我们分析一下，该种解决方案的优缺点。

优缺点是通过比较而得到的，我们对比的解决方案假定上述的套餐最终定义是通过Hard-Code实现的，那么：

优点：

• 自变量定义显式化

• • 我们可以快速地知道所谓的 渠道、营销入口、省份等概念，在套餐系统中起到的作用是什么

• 最终套餐表现显式化

• • 只要确定了自变量的值，我们就可以从，配置表中抽取出特定配置，构建出一个按照行优先级排序的矩阵，从而快速得到最终套餐的表现

• 节约开发资源

• • 在确定套餐内容过程中，可以统一处理所有自变量对应的属性

  • 在没有新增 因变量时，开发工作量极少，甚至免于开发

• 业务获得了其最大的灵活度

• 特殊逻辑外置化

• • 业务有时会像上面提出的“这个套餐不能被任何其他自变量配置修改”的需求时，我们可以让其自行通过配置实现，而不用污染我们的代码

  • 至于后续这个业务配置变得怎么乱，其都是由于业务自身思考不合理导致，配置信息由业务主管，其需要为自己的配置负责。

缺点：

• 可能需要给业务提供一个友好的配置界面，需要点开发工作量

上面的电话套餐只是一个举例，我们可以很容易地将这个简单的设计迁移到其他类似的场景，如汽车定制套餐，贷款套餐等。

关于作者

作者曾在两家排名前三的股份制商业银行工作过，目前在一家排名前二的互联网银行工作，做过业务，做过中间件，做过架构，也带过小团队。

公众号会定期分享个人关于 技术、架构、业务 等的思考，欢迎关注公众号。

同时欢迎添加个人微信skyesx探讨技术相关问题，请备注名字+公司。

本文有任何不妥欢迎留言斧正，若本文能带给你收获，请不吝分享！

推荐阅读

从分治的思想到架构的设计

谈复用的成本与中台的建设