详情字段展现问题的解决模型设计

问题背景

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

不良模型

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

单个字段的多处改动

如今，来了一个新业务 C ，须要展现抵扣后的实付款金额。简单的方式是，直接在 R 上减去抵扣金额便可；假设又来了个新业务 B ，须要在条件 a 下显示实付款金额，在条件 b 下显示另外一种原订单金额。 那么，也在 R 上作处理。 这样，每一个新业务来了， R 都被改动一次。 R 变成了一个隐形的全局变量。 每改一次，使用到字段 R 的风险就累加一次，然后来接手的人是无法回归以前全部涉及的业务的。

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

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

解决方案：字段值肯定后不可变； 创建字段之间的关联关系，修改时谨慎； 将 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框架和代码手段直接保证依赖关系无误。

小结

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

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