最实用的中台入门介绍( 五 )

以上问题先放着，因为账号和账号状态息息相关，我们再看“停用删除销售员账号”这个需求。
3. 停用、删除销售员账号，其实本质上是在改变账号的状态属性，而不是真的把账号删除了，而每个业务对账号状态的叫法肯定都是不一样的，每个账号状态不同，对业务逻辑的影响也不同，所以我们思考的问题是1）功能本身的逻辑是什么
我们中台要如何定义销售员账号的状态，才能更加通用和泛化？
2）非中台能力的业务解决方案
各种状态带来的不同的业务影响，是否要沉淀到中台？
4. 通过这些思考，我们最终沉淀的能力和功能如下1）提供创建账号的原子能力
做最基础的一个人在一个门店下只能创建一个账号的通用校验，其余业务属性较强的账号数量等等的校验逻辑由业务自行完成，只要调接口，我们就创建。
2）提供与销售员账号属性相关性较强的独立字段的存储
比如所在门店 id（但中台不会叫门店id字段），其余字段作为扩展字段提供存储能力。一些明显与业务域相关性较弱的字段（在导入导出中发现的），中台不存储，但与业务共同商讨如何解决基于这些字段的查询问题。
3）中台的账号体系是内部底层能力品做好规划，并向研发阐述清楚
4）提供通用的账号状态字段
为兼容大部分商户都可能有的审核流程，提供4个账号状态：待激活、已激活、已冻结、已注销。业务侧自行对应，自行控制每个状态带来的业务逻辑，如果业务有审核，可以考虑创建待激活状态的账号，如果没有审核可以直接创建已激活状态账号。
本次案例中业务侧的禁用和启用可以对应中台的冻结和激活。
这样，中台落地的思路就出来了，过程中只是要更注重通用和泛化的逻辑，描述清楚哪些是中台做，哪些是业务侧自行实现，系统交互流程是什么就可以了。
六、最后我举的两个案例其实比较简单，中台真正落地时还要考虑很多东西，产品的底层能力是通用的，只是中台更注重拓展性和抽象能力。
今天只是讲了一些入门，希望能让看这个内容的人有个具象的感知，虽然各个中台由于领域不同，各自能力域和落地方法也不同，但是各个中台依然能够抽象出一些共性的东西，后续再具体讲解。
【最实用的中台入门介绍】