業務中台的價值主要體現在對通用化業務能力的沉澱、整合，通過對可復用業務流程和業務功能的設計，向不同業務方提供標準化且可擴展的服務能力。本文來聊一聊筆者工作過程中設計的通用化黑名單平臺，通過將用戶管控能力的下沉，為各業務團隊提供一套通用的黑名單/白名單業務能力。

業務定義

黑名單平臺，泛指在業務流程當中，需要對特定用戶進行管控的方式，通常會有黑名單、白名單兩種用戶類型。

業務場景

在風控識別、業務運營等流程當中，會涉及到對於某類用戶進行“特殊對待”，比如惡意用戶、高風險用戶，在業務流程中可能會增加對用戶的使用功能的限制，這類用戶就屬於黑名單用戶。在不同的業務場景中，會基於不同規則去定義黑名單用戶，並這種符合這類特種的用戶進行統一化的管控。

當然還有一類特殊的用戶群體，他們因為使用場景的特殊化也可能命中黑名單用戶的規則。但是業務場景中又是允許這類用戶存在的，那麼這類用戶就屬於白名單用戶，屬於凌駕於黑名單規則之上的一類特殊用戶群體。

業務問題

目前在現有中台架構下，不同業務模塊都維護各自的黑名單體系，存在同一個業務場景的黑名單維護多套，或者同一套黑名單可以多個業務團隊共用的問題。這就導致各團隊開發既可能產生數據冗餘，重覆開發資源浪費的問題。

基於當前的問題，通過搭建中台黑名單平臺，由各業務團隊介入黑名單平臺，針對各業務場景維護統一黑名單，可以由不同業務團隊共享黑名單數據資源進行業務使用。

業務邊界

既然做通用化，那麼黑名單平臺盡可能不做具備業務屬性的邏輯，即通用戶平臺負責提供黑名單/白名單數據的統一使用服務，也就是針對數據的增、刪、改、查能力。同時，為了保證各業務使用方可以實時獲取數據，平臺提供一套消息廣播機制，可以讓業務使用方可以快速獲取數據的更新狀態，即時針對不同狀態做出業務響應。

業務架構

基於上面提到的業務場景、業務邊界，設計了業務架構模式如下：

業務設計

（1）通用化平臺由業務方接入，針對不同業務場景和業務規則，由業務方（如上圖中業務方A、B）定義什麼是黑名單用戶、什麼是白名單用戶；由通用化平臺提供黑名單數據的統一服務，這個服務包含增刪改查能力。

（2）業務方（如上圖中業務方A、B）可以通過通用戶平臺提供的前端可視化頁面，通過給不同業務方配置不同權限體系，支持業務方進行數據的增刪改查。同時也支持基於系統調用的API接口方式，進行數據的使用。

（3）為保證數據更新後的即時響應，在數據更新後，如數據的新增、刪除，通用化平臺通過消息廣播機制，向業務使用方（如上圖中業務方C、D）進行廣播，如果業務方關係數據更新消息，可基於業務場景做出相應的業務動作，保證數據更新與業務的同步性。

中台化設計的關鍵

（1）統一化

在設計數據的使用方式方面，做了盡可能的統一化設計。在設計底層數據接口方面，針對增刪改查的數據接口，先對盡可能全的業務場景進行梳理，針對不同顆粒度的業務進行規劃，保證數據接口服務的統一性，後續各業務團隊接口，都是統一的接入流程和接口服務。

（2）個性化

針對不同業務場景，數據的表現形式終歸會有不同的地方，除了對整個業務流程中沒有異議的數據內容進行標準化定義外，為滿足不同團隊的業務需求，在數據存儲方面，數據結構中增加了可擴展的json字段。這個字段的數據內容由各業務方自助定義數據的業務含義，在數據查詢時基於各業務的團隊的場景進行解析後使用，既保證了各業務團隊數據使用的個性化需求，由保證了中台通用化模塊的通用能力。

（3）擴展性

對於黑名單/白名單數據存儲，數據存在多維度屬性，通過數據業務類型分類進行區分，例如用戶維度類型，可通過枚舉區分身份證號、會員卡號、手機號等類型，字段的類型設計相對兼容，在後續數據類型擴展上，可以做到減少底層邏輯的重新開髮帶來的時間、資源成本。

（4）如何做到上述3點呢？

關鍵是要對業務有充分的瞭解，這樣才能更好的把握統一化和個性化的平衡。例如，針對於用戶維度的黑名單設計，要對當前業務場景中標識用戶的方式有相對全面的瞭解：手機號、會員卡號、微信賬號、支付賬號等等，只有對實際業務的瞭解，才能設計符合業務方需求的功能。

綜上

所有的中台化產品設計都是在對業務充分瞭解的基礎上，將統一化、個性化、擴展性進行設計與權衡，當然在方案落地過程中不可避免的要做出各種各樣的妥協與讓步，但是作為業務中台設計者，要堅守產品設計的邊界與底線，這才是中台產品存在的意義與價值。

#專欄作家#

記小憶，公眾號：PM龍門陣，人人都是產品經理專欄作家，OTA中後臺產品經理。

本文原創發佈於人人都是產品經理，未經許可，禁止轉載

題圖來自 Unsplash，基於 CC0 協議