业务中台的价值主要体现在对通用化业务能力的沉淀、整合，通过对可复用业务流程和业务功能的设计，向不同业务方提供标准化且可扩展的服务能力。本文来聊一聊笔者工作过程中设计的通用化黑名单平台，通过将用户管控能力的下沉，为各业务团队提供一套通用的黑名单/白名单业务能力。

业务定义

黑名单平台，泛指在业务流程当中，需要对特定用户进行管控的方式，通常会有黑名单、白名单两种用户类型。

业务场景

在风控识别、业务运营等流程当中，会涉及到对于某类用户进行“特殊对待”，比如恶意用户、高风险用户，在业务流程中可能会增加对用户的使用功能的限制，这类用户就属于黑名单用户。在不同的业务场景中，会基于不同规则去定义黑名单用户，并这种符合这类特种的用户进行统一化的管控。

当然还有一类特殊的用户群体，他们因为使用场景的特殊化也可能命中黑名单用户的规则。但是业务场景中又是允许这类用户存在的，那么这类用户就属于白名单用户，属于凌驾于黑名单规则之上的一类特殊用户群体。

业务问题

目前在现有中台架构下，不同业务模块都维护各自的黑名单体系，存在同一个业务场景的黑名单维护多套，或者同一套黑名单可以多个业务团队共用的问题。这就导致各团队开发既可能产生数据冗余，重复开发资源浪费的问题。

基于当前的问题，通过搭建中台黑名单平台，由各业务团队介入黑名单平台，针对各业务场景维护统一黑名单，可以由不同业务团队共享黑名单数据资源进行业务使用。

业务边界

既然做通用化，那么黑名单平台尽可能不做具备业务属性的逻辑，即通用户平台负责提供黑名单/白名单数据的统一使用服务，也就是针对数据的增、删、改、查能力。同时，为了保证各业务使用方可以实时获取数据，平台提供一套消息广播机制，可以让业务使用方可以快速获取数据的更新状态，即时针对不同状态做出业务响应。

业务架构

基于上面提到的业务场景、业务边界，设计了业务架构模式如下：

业务设计

(1)通用化平台由业务方接入，针对不同业务场景和业务规则，由业务方(如上图中业务方A、B)定义什么是黑名单用户、什么是白名单用户；由通用化平台提供黑名单数据的统一服务，这个服务包含增删改查能力。

(2)业务方(如上图中业务方A、B)可以通过通用户平台提供的前端可视化页面，通过给不同业务方配置不同权限体系，支持业务方进行数据的增删改查。同时也支持基于系统调用的API接口方式，进行数据的使用。

(3)为保证数据更新后的即时响应，在数据更新后，如数据的新增、删除，通用化平台通过消息广播机制，向业务使用方(如上图中业务方C、D)进行广播，如果业务方关系数据更新消息，可基于业务场景做出相应的业务动作，保证数据更新与业务的同步性。

中台化设计的关键

(1)统一化

在设计数据的使用方式方面，做了尽可能的统一化设计。在设计底层数据接口方面，针对增删改查的数据接口，先对尽可能全的业务场景进行梳理，针对不同颗粒度的业务进行规划，保证数据接口服务的统一性，后续各业务团队接口，都是统一的接入流程和接口服务。

(2)个性化

针对不同业务场景，数据的表现形式终归会有不同的地方，除了对整个业务流程中没有异议的数据内容进行标准化定义外，为满足不同团队的业务需求，在数据存储方面，数据结构中增加了可扩展的json字段。这个字段的数据内容由各业务方自助定义数据的业务含义，在数据查询时基于各业务的团队的场景进行解析后使用，既保证了各业务团队数据使用的个性化需求，由保证了中台通用化模块的通用能力。

(3)扩展性

对于黑名单/白名单数据存储，数据存在多维度属性，通过数据业务类型分类进行区分，例如用户维度类型，可通过枚举区分身份证号、会员卡号、手机号等类型，字段的类型设计相对兼容，在后续数据类型扩展上，可以做到减少底层逻辑的重新开发带来的时间、资源成本。

(4)如何做到上述3点呢？

关键是要对业务有充分的了解，这样才能更好的把握统一化和个性化的平衡。例如，针对于用户维度的黑名单设计，要对当前业务场景中标识用户的方式有相对全面的了解：手机号、会员卡号、微信账号、支付账号等等，只有对实际业务的了解，才能设计符合业务方需求的功能。

综上

所有的中台化产品设计都是在对业务充分了解的基础上，将统一化、个性化、扩展性进行设计与权衡，当然在方案落地过程中不可避免的要做出各种各样的妥协与让步，但是作为业务中台设计者，要坚守产品设计的边界与底线，这才是中台产品存在的意义与价值。

#专栏作家#

记小忆，公众号：PM龙门阵，人人都是产品经理专栏作家，OTA中后台产品经理。

本文原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议