我理解的複雜業務場景，指的是處理鏈路長（乙個完整流程需要多個節點處理），鏈路中某個節點的分支情況多（同一節點下根據不同業務型別有不同的處理邏輯），資料結構繁多且複雜（資料流入時結構越複雜，則說明處理內容增加，業務場景更為複雜）
對於複雜的業務場景，建議可以從下面幾個方面參看處理：
1.將處理鏈路分模組進行處理和管理
通過分模組，可以讓各個子單元只關注與自己負責的內容，降低系統耦合程度，降低專案運維成本
2.通過外觀法和模板方法結合使用，增加系統可維護的能力
舉個例子，比如電腦啟動，我們可以寫個方法，裡面只有四條邏輯，主機板通電/顯示器通電/滑鼠鍵盤通電/記憶體資料處理，但是具體的邏輯放到單獨的方法裡面。在長鏈路的處理中，我們通過外觀的方式，可以讓整個業務流程清晰可見，專案結構越是清晰，**可讀性就越高，程式運維成本就越低
3.中颱思想和擴充套件點的應用
通過中臺提供通用功能和流程，通過擴充套件點實現特定品類業務場景的定製化邏輯，但是擴充套件點的實現的最優解是通過框架去支援和實現（阿里這邊也是有特定框架的）。中臺思想+擴充套件應用+logic，完成通用邏輯i和定製化邏輯的完美組合，解耦了複雜性~
4.資料結構的處理
邏輯複雜性已經得到處理，但是不同業務品類它們的資料結構是否通用？是否有定製化？如果是通用的還好處理，如果不通用，是採用關係型資料儲存還是非關係型資料儲存？現在先討論關係型儲存的解決方式，關係表中新增擴充套件字段，還是不同品類增加新錶？在增加擴充套件欄位後，因為不同品類流程入參可能不一致，中臺介面需要相容所有入參？如果流程入口只有乙個，介面肯定只能有一處，最終的形式為擴充套件應用作為中颱的乙個子模組；如果不同品類之間，流程入口不一樣，比如品類a有個單獨的**，品類b有個單獨的**，那麼，整個流程入口就可以有多個，擴充套件應用分別提供入口，此時中臺應用便成了擴充套件應用的服務提供方。擴充套件應用提供介面，並呼叫中臺服務完成整個邏輯處理
資料結構明明準確
React Redux與複雜業務元件的復用
從redux的state中讀取使用者token。由於這個元件需要讀取存放在redux state中的使用者token，並且包含非同步請求，將它的狀態放入redux中管理，並且使用redux saga處理非同步請求是非常合適的。但是在元件的復用性上，我們遇到乙個難題，由於redux本身並不提供模組化功...
業務總結004 檢驗專案時間輪實踐與庫存實現方案
2020 年底公司和阿里健康合作了乙個檢驗專案，由我司提供檢驗專案 商品 取樣點 商戶 庫存等底層資料，與阿里健康開發對接後在支付寶平台進行線上預售，開發流程其中也包括訂單資料的互動。專案開發期間踩了比較多的坑，做了很多優化，其中也包含一些有意思的技術實現方案。某些業務場景下，我們需要頻繁呼叫阿里健...
基於業務場景與使用者行為，如何設計更友好的表單？
我們每天都會接觸到各式各樣的表單頁面，其中包括登入賬號 填寫單據 購買產品 發布資訊等。它作為所有產品裡最常見也最普通的設計元素，往往最容易被忽略它們該有的體驗細節，而引起使用者使用中的挫敗感。本篇文章主要通過業務場景和使用者行為的角度來分析，如何打造體驗友好的表單介面。目錄一 互動設計下的業務場景...