共计 1296 个字符，预计需要花费 4 分钟才能阅读完成。
咱们都晓得中台和平台都是企业通用能力的抽取与积淀这是毋庸置疑的，那两者之间的区别又是什么呐？为何在平台之上又提出中台概念呐？笔者最近在拜读欧翻新大神大作《中台架构与实现 — 基于 DDD 和微服务》偶有感悟暂且大胆一说如有舛误及误人子弟之处望各位读者不吝赐教，轻拍轻拍。
首先中台与传统平台的的区别就是中台提供的的是企业级的解决方案更加贴近业务一线而平台一般来说提供的都是非企业级解决方案其定位更多是通用性能并且有远离业务的偏向以期提供更大的通用性，其造成两者区别的实质起因在于两者的定位和 owner 不同。具体来说平台只提供了企业级的性能或者解决方案的一部分须要前台部门在此基础上做额定大量开发能力提供用户面向用户的残缺性能。这会造成两个问题一个是前台部门还须要破费额定的人力开发，如果性能类似则势必造成反复开发的人力节约再一个就是因为各前台都在平台根底上做二次开发势必造成用户体验在类似性能上的不统一。
举例笔者公司微信平台为例阐明：
背景就是微信平台提供的前台调用方可通过 openId 换取 user id 性能。然而微信绑定时候是能够绑定多个用户 id 的，平台在返回时候会把这个 openid 对应的所有绑定的 user id 都返回给调用方甚至包含解绑的 user id，并加上绑定状态作为辨别。
从平台的角度来说这个设计没有问题根本提供了所有调用方可能用到的所有数据提供了最大的通用性因为他无奈确定各个调用方是如何应用这个 openId 的然而这里就会有后面提到的两个问题比方线下购物团队须要通过微信 open id 来确认用户身份发现绑定了多个可能会感觉该账号存在问题则间接回绝认证。而另外团队可能感觉绑定都须要通过十分紧密的步骤，平安行都是能够保障的不如每次都取最新的好了。这样两个团队都须要额定开发本人的认证性能并且给用户体验是不统一的，用户在一个性能上能够绑定胜利换个性能点居然怎么绑定都不行必定会十分的 confused。
如果是最为一个微信认证中台来说设计可能是这样的：他提供一个通用的用户微信平台认证性能，如果 open id 绑定了多个则比方间接返回最新的 user id 这样一个企业级的解决方案（为甚说是企业级的因为这个性能对用户来说就是一个残缺的性能）。这样不同团队在应用时候就间接拿到了 user id 不须要额定开发并且对用户来说体验也会十分的统一。
大家看出两者实现上的背地的起因了么？那就是两者背地的定位和 owner 不同，作为微信平台来说他只是微信相干性能的一个汇聚他并不理解具体的应用场景是什么样的因为他的 owner 够不到前台，而后者作为中台他的定位和 owner 就是用户认证说白了他的 owner 够的到前台他说了能算。
所以说如果企业要做中台转型必定不仅仅是 IT 部门一帮程序员闷头梳理模型闭门造成就能做成的这个波及到公司整体组织架构调整以及思路上的一个转变。一个是业务部门要认同这个事件业务部门自身就要界定好那些性能是中台 care 的那些性能是前台 care 的，另外一个是中台的演进上中台要作为一个企业级计划提供团队去演进和迭代当然是也能够承受前台部门提供的需要。
中台构造与实现 基于 DDD 和微服务
