詳情字段展示問題的解決模型設計不佳導致埋坑
問題背景
交易詳情頁，往往涉及到展示交易金額詳情，以及一些基於金額的文案展示和操作。隨著業務的多樣化發展，部分核心金額字段，會有針對不同業務的很多改動，往往某個改動就會影響到其他業務場景下的展示，或者影響原有功能。
不良模型
假設有一個實付款金額字段 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 語句。
如此，這個字段展示的問題就得到了解決。這種思想，也可以運用到任何改動疊加組合的問題上。
小結
本文探討了如何用模型思想去思考和解決字段顯示問題。組件化、組件編排、配置是解決業務改動疊加的基本方法；不可變、語義唯一且確定、統一管理，是確保不出問題的技術手段。
因此，拿到一個問題，不是急於去解決，而是思考它所基於的模型，從模型層的角度去解決，能獲得更優雅可維護的解決方案。
詳情字段展示問題的解決模型設計不佳導致埋坑