架构决策的弹性

一说到架构，大家首先想到的应该是一些架构原则，例如分层，例如开闭，例如隔离。但是，在一定的特定条件下，架构是需要适应产品或者场景的需要灵活变化的。就好比变色龙一样，需要适应环境的变化，把自己和环境融为一体。架构决策是否有足够的弹性，是否可以随机应变，往往也是资深架构师和普通架构师的显著区别之一。

这个随场景变化的架构，也就是架构的弹性，比较难用理论来描述。这里我们就通过几个现实中例子进行体会。

例 1 如何描述一个组合关系

场景：在设计组合产品的过程中，需要存储组合产品的组合单和原子产品单之间的关联关系。

第一版本设计中，架构师将这个关系沉淀在了子单据上，子单据上有一个 composit_order 字段描述这两者的关系。

架构选择：首先，这个关系在领域模型上就是一个一对多的关系。现在要进行决策的是在数据模型上怎么设计，是放在组合单，还是放在子单据，或者单独做一个关系表。

架构决策：首先，在这个组合产品中，原子产品能力是既有的能力，也是会被各类其他产品复用的能力，包括域外和域内。同时在现状下，原子能力也可以独立对客透出。所以，这个组合关系是组合产品所特有的领域概念，原子产品理论上应该不感知。所以，这个关系沉淀到组合产品中会比较合适。同时考虑到查询的效率，单独设计关系表比在组合单中用扩展字段描述更合适。

结论：领域模型和数据模型的设计需要充分考虑各自领域的边界，尽量不要将本领域边界内的概念对外透出，同时不要让其他领域边界内的概念污染本领域。

例 2 集中式 vs 分布式

场景：在销户场景下，注销后，注销信息各域的使用方式可以有两种选择：统一在会员管理 vs 通知到各业务域进行管理。

架构决策依据：这个架构决策需要从如下方面进行分析和比较：

• 一致性优先还是可靠性/性能优先。

• 写优先还是读优先。

• 是否有数据保护诉求。

架构决策过程：对于这个销户的场景，一致性还是优先需要考虑的，注销的用户需要在同一个时间内抹除信息和禁止资产操作，相应的性能可以放在第二位。销户是偶发的操作，肯定是读优先的。用户信息有数据保护诉求，但是销户状态无数据保护诉求。根据二三点，通知各域会是一个比较好的选择。但是考虑到第一点，放在会员统一管理是一个明显更合适的选择。同时，第一点上两个方案的差异会比二三点中方案间的差异更明显，所以选择会员统一管理，各个域来咨询是一个合适的方案。同时，会员的缓存机制比较成熟，在性能上也不会引起多大的问题。

结论：架构决策是一个比较的过程，很难遇到 100 分和 0 分的对比，更多的是 60 分和 40 分的 PK。

例 3 交易和查询模型/存储的选择

场景：对于交易信息的列表查询，是否需要单独的读库，甚至和交易单据异构的视图模型。

架构决策点：对于这个选择，非常依赖场景的输入：

• 查询的粒度和写入的粒度是否一致，是否需要关联多个域的数据进行联合查询。

• 是否有非常大的查询量，是否会对现在交易产生冲击。

• 是否对于数据一致性的要求非常高。

如果查询和交易模型区别不大，同时查询量较小，数据一致性要求高，交易和查询共用一份数据模型和数据存储就比较合适。

如果查询交易量大，一致性要求可以降级，单独拆分读库可能就是一个合理的选择。

如果查询有较多的数据聚合，亦即查询的模型其实和交易的模型是异构的，那么用数仓同步+查询的方式会更合理。

结论：随着分析维度的增加，架构的决策会有显著的变化。