多业务场景下的详情字段展示问题的求解

问题背景

交易详情页，往往涉及到展示交易金额详情，以及一些基于金额的文案展示和操作。随着业务的多样化发展，部分核心金额字段，会有针对不同业务的很多改动，往往某个改动就会影响到其他业务场景下的展示，或者影响原有功能。

不良模型

假设有一个实付款金额字段 R 及展示。现在很好办，直接展示这个字段 R 即可。

单个字段的多处改动

现在，来了一个新业务 C ，需要展示抵扣后的实付款金额。简单的方式是，写个条件语句，在抵扣场景下直接在 R 上减去抵扣金额即可；假设又来了个新业务 B ，需要在条件 a 下显示实付款金额，在条件 b 下显示另一种原订单金额。 那么，又添加了两条条件语句，也在 R 上做处理。 写出的代码如下：

R = order.getPrice();
if (业务场景 A) {
     R = R - discount;
}
if (业务场景B) {
    R = R - postage；
}
if (业务场景C) {
    R = order.getOriginPrice();
}
// ...

这样，每个新业务来了， R 都被改动一次。 R 变成了一个隐形的全局变量。 每改一次，使用到字段 R 的风险就累加一次，而后来接手的人是没法回归之前所有涉及的业务的。

不良模型： 多个业务修改同一个字段，导致该字段变成了隐形的全局变量，而全局变量是很容易出BUG并且问题排查很费时。如果是比较重大的故障，导致的损失将是难以估量的。

实际问题： 有一个实付款金额字段 R ，以及一个原来的实付款金额 OriginR， 在后期字段信息格式化的时候设置了 OriginR = R 。 在某个业务改动中， 将 R 进行了改动，这样影响了 OriginR ，从而导致了问题。

单个字段承载多个语义

现在，来了个新业务 P，需要展示 W 金额。 由于 W 金额的含义在其业务语境下与 R 相同，前端为了展示方便，就直接使用了 R ； 又来了个新业务 S，基于类似的缘由，与实付款金额的含义相同，也使用了 R 。 R 承载了多个业务语义，依赖于后端来保证这些语义。但后端并没有记录这些语义。 现在，来了个新业务 T ， 基于某种原因，前端不能直接再显示 R ，而要显示改造后 R' 。 但是 R' 没有考虑到前面的某个业务 S，导致 S 的展示出错。

不良模型： 一个字段承载多个业务语义。 当不能直接使用原来的字段时，在原字段上做的改造很容易遗漏之前的某个业务语义。

以上两种情况，都需要遍历整个工程的所有使用到这个字段的地方，并在合适的时候修改或添加逻辑。这样成本是很大的。也很容易遗漏。

解决模型

基本思路

每个问题都可以抽象出一个解决模型来处理。模型是实体及关联关系。从模型层来透视问题的本质。如果解决模型建立不佳，坑会很早埋下，出问题只是迟早的事情。

就字段展示问题而言，实体是一个个单个字段，而关联关系则是字段之间的依赖关系。 比较好的解决模型是：

• 每个字段的业务语义确定且唯一；

• 字段的值确定后不可变；

• 使用频度高的字段，相关代码统一到一处管理，而不是分散到工程的迷林里。
  
  

字段分两种：

• 核心常用字段： 这些字段往往经常被改动，其改动逻辑需要统一到一个地方； 其改动逻辑可以针对不同的业务做成组件化然后进行组合装饰，或者基于这个字段根据不同的业务生成衍生字段； 确定基于这些核心常用字段的字段的依赖关系并文档化。

• 不常用字段： 这些字段通常不怎么变更， 确定确切的语义展示即可。

重点解决核心常用字段的展示问题即可。

实际问题

改动叠加组合

一个实际问题是：多个业务对同一字段的改动必须能够组合。 比如业务 A 对字段 R 做了改动 x , 业务 B 对字段 R 做了改动 y ，业务 C 对字段 R 做了改动 z 。

• 如果所有改动都必须体现在 R 。 直接的想法是直接修改 R 。但这种方式，容易影响直接依赖于 R 的字段和功能，这些字段和功能隐藏在难以明显看到的代码密林中。

• 更好的一种方式是在 R 的基础上，生成所需要的衍生字段 R'。比如 通常场景下，需要叠加所有的改动；在 S 场景下，需要 x 与 y 改动；在 T 场景下，需要 y 与 z 改动。

这实际上是一个通用的问题，需要灵活叠加各种业务的改动。怎么解决这个问题呢？

• 组件化。 首先，将所有针对这个字段的改动做成组件。

• 组件编排。 在组件化之后，可以进行组件编排，根据所需来叠加改动。装饰器模式，正适合于这种场景。

• 配置。 根据不同场景，配置不同的组件执行顺序，生成并配置不同的衍生字段。

注意到，始终是不改变最初的基本实付款金额 R 的。 只是组合装饰不同的组件，处理 R 得到衍生字段 R'， R'' , R''' , ... 那么前端同学可能要问了：我需要根据不同场景去使用这么多 R 吗 ？ 这就是最后一步配置的意义。 根据配置来选取不同的 R ，而不是写一堆 if-else 语句。

如此，这个字段展示的问题就得到了解决。这种思想，也可以运用到任何改动叠加组合的问题上。

字段依赖关系

常常会有若干个次要字段依赖于一些核心常用字段。如果没有注意到这些依赖关系，很容易因为改动常用字段，影响次要字段，从而影响现有功能。

如何管理字段依赖关系呢 ？个人建议：

• 在字段的注释上写明依赖关系和约定，引起注意；

• 通过DAG框架和代码手段直接保证依赖关系无误。

小结

本文探讨了如何用模型思想去思考和解决字段显示问题。组件化、组合装饰、配置是解决业务改动叠加的基本方法；不可变、语义唯一且确定、统一管理，是确保不出问题的技术手段。

因此，拿到一个问题，不是急于去解决，而是思考它所基于的模型，从模型层的角度去解决，能获得更优雅可维护的解决方案。