中台要做什么？
 

技术中台就是对各个商品中心进行能力的抽象，为各业务线提供底层的商品能力。

 

而各业务线就是基于这些基础能力，去搭建自己的商品中心，做更上层的商品相关的产品功能。

 

这样每个业务的商品中心都只服务于自己，更加完美的契合业务需求，使用也更高效，同时基于中台能力的商品中心搭建起来也更加便捷和迅速。

 

所以对于中台来说，如何避免弱抽象，又不过度抽象，就变得非常有难度了。

 

弱抽象，就意味着有很多业务的东西夹杂其中，每次迭代都可能涉及到中台能力和接口的改动。

 

过度抽象，就会导致中台体现不出价值，业务开发工作依然繁重，甚至因为新增对接中台而加大工作量。

 

中台进阶：

 

那么是否这样就是一个最终形态了？并不是。

 

假如中台对外提供的是最基础的能力，那么对业务来说，他需要花费很多时间通过这些基础能力接口去做上层的业务拼装，并引入基础能力之外的业务逻辑，而这些业务逻辑可以由中台提供，也可以由业务自己来实现。

 

那么考虑到让业务效率最大化，最好的方式是什么呢？提供基础能力，其实是相对简单的，工作量的大头其实是业务。

 

那么假如中台能够以一种通用性的方式，帮助业务完成一部分业务需求，何乐而不为呢？

 

很多书中都在告诉大家，中台就只做抽象，只提供基础能力，虽然前提是对的，但是忽略了很重要的一点，中台的第一目的就是帮助业务减负，最大化业务效率。

 

如果做不到这点，中台再强调抽象，再强调低耦合，都对企业的发展没有太大帮助。

 

所以换个思路来讲，比如业务中，做营销活动的时候，不同类型的营销活动对用户参与门槛都有不同的限制，类似这样的限制规则其实非常多，10 个活动都要用到这样的限制规则，且这些规则离不开类似（是否新用户、是否用户等级大于 XX、是否活跃用户等等），既然如此，为何不为业务去提供一套整合的规则池，并提供一套门槛校验能力，进一步帮助业务减负？

 

这样的例子有很多。可以说这样的规则池也是一种抽象，但其实更像是枚举，因为每一个规则都可能完全不同，需要一个个建立起来。