詳情字段展現問題的解決模型設計

問題背景

交易詳情頁，每每涉及到展現交易金額詳情，以及一些基於金額的文案展現和操做。隨着業務的多樣化發展，部分核心金額字段，會有針對不一樣業務的不少改動，每每某個改動就會影響到其餘業務場景下的展現，或者影響原有功能。

不良模型

假設有一個實付款金額字段 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框架和代碼手段直接保證依賴關係無誤。

小結

本文探討了如何用模型思想去思考和解決字段顯示問題。組件化、組件編排、配置是解決業務改動疊加的基本方法；不可變、語義惟一且肯定、統一管理，是確保不出問題的技術手段。

所以，拿到一個問題，不是急於去解決，而是思考它所基於的模型，從模型層的角度去解決，能得到更優雅可維護的解決方案。