架构决策系列 1：通用模型 or 专用模型

作为架构师，架构决策是日常重要的工作之一。但是架构决策又是挑战最大，最不容易做好的。架构决策的失误，往往又会引起极大的后果，甚至可能影响到一个软件项目的成败。推出架构决策系列文章，通过实际的例子，来说明架构决策的最佳实践。

软件的构成，无非就是模型+服务+逻辑，模型又是其中最重要的组成。在做模型设计的过程中，我们往往会面临如下的架构决策：应该是基于当前的业务诉求设计专用的模型，还是应该考虑到后续的扩展性设计一个相对通用的模型呢？

面对这个选择，很多初级的架构师往往会从技术视角出发，认为设计一个通用的模型挑战更大，实现上看起来也更优雅。但是，过度的通用设计，反而很可能会丢掉相应业务场景的特质，最后导致宽模型大字段的频繁出现。

我们来举一个实际例子，在设计和渠道的交互模型的时候，我们是应该用原子单组合单这种通用的模型，还是应该根据卡支付、钱包支付、扫码支付等，去设计更专用的模型呢？

对于这个选择，我们可以从如下方面进行考量：

1. 场景是可枚举的还是可以无限扩展的。对于支付这个 case，支付资产类型基本就是卡、钱包、现金、数字货币等有限的类型。

2. 各个业务场景之间的共性更多还是特性更多。针对上述的支付场景，更多的是特性而不是共性。比如卡支付，资产是信用卡的四要素，交互是 auth/capture/void/cancel/refund/chargeback 等。对于钱包支付，资产是钱包的 token，交互是 create/verify/confirm。对于扫码支付，资产是码，交互是扫码和拉起收银台。场景之间的区别还是相当大的。

3. 目前的业务诉求是部分的还是全部的。如果目前的业务诉求只是部分功能，用通用化的设计就不是很合适。因为资源不允许做大量的需求分析和设计来支持所有场景。设计粗糙的通用模型，反而会为未来的扩展带来不利的影响。

基于上述考虑，我们在第一个版本进行模型设计的时候，大概率应该选择专用模型去支持特定的场景。

推而广之，我们在做通用模型还是专用模型架构决策的时候，可以遵循如下的思路：

1. 大的场景之间往往倾向于用专用模型。首先大的场景基本是可枚举的数量有限的，而且场景和场景之间的差异会相对较大。这就好比冰箱、洗衣机、空调，没有任何一家家电企业会用同一个流水线去生产。

2. 大场景内部，各个细分场景之间，倾向于用通用模型去支撑。比如卡支付内部的信用卡和银行卡支付；代扣场景、2D 场景和 3D 场景。对于一个通用的模型，内部增加资产、认证的扩展点，来实现不同的业务分支。这就好比同一款的汽车，通过不同配件的选配，实现个性化。

3. 前期迭代不要过度考虑通用，先针对当前的产品需求设计好模型，等未来场景丰富了再对模型做进一步的迭代，该通用的地方通用，该专用化设计的地方单独设计。