由 dawei 在听完他的叙述之后，我忍不住笑出声来，并对他说：“小伙子，你这哪是中台啊?!这分明是三层架构(3-Tier Architecture) 啊……”从表情上看，我感觉他有点懵圈，小声问了一句：“三层架构?MVC吗?”我摇了摇头，给他从头到底普及了下3-Tier Architecture，并且强调了界面层(User Interface layer)、业务逻辑层(Business Logic Layer)、数据访问层(Data access layer)的分层目的是为了“高内聚，低耦合” 。他听完摇了摇头，似乎不太理解，并追问：“那么 ‘业务逻辑层’ 与 ‘业务中台’ 的区别是什么呢?”我把他拉到一旁的咖啡厅，找了个座，并在网上翻到一张3-Tier Architecture的结构图，然后对他说：“说实话，虽然单纯通过几张图和口述，我无法了解你们的业务背景与现状。”
“但你所描述的那个 ‘业务中台’ ，最多只能算是一个软件体系架构中的业务逻辑层，压根跟 ‘中台’ 没半毛钱关系。”
他听完，一边摇头，一边说：“不对啊，我们技术老大可不是这么说的……”我很好奇，忙追问他。按他的说法，在他们公司内，大家都认为中台是一种松耦合结构的架构模式，主要是用来解决层与层之间的依赖问题的。也就是说，他们公司的 “业务中台” 价值主要体现在以下几点：
1、把标准化的服务下沉到 ”业务后台”，把非标准化的服务上浮到 “业务中台”。
2、有了 ”业务后台”，一旦上层的设计改变，对于其调用的底层而言没有任何影响。
3、大部分的业务需求只需要捣腾 ”业务中/前台”，似乎成本更低，效率更高了。
听完他的这番言论之后，我愣了近十秒钟，一时间不知道说些什么。大脑给我的第一反应是把一堆 “吐槽” 喷在他脸上，但最终理智还是战胜了冲动。我朝他微微的笑了笑，说了一下我的看法。就像我在 #请你们不要调侃中台，它是我们赖以生存的镰刀#中讲述的那样，业务中台也好，技术中台也罢，它并不是一种技术实现，而是一种技术战略。而业务逻辑层可不是战略，它只不过是专门用来处理软件业务需求的一层，是用来实现设计模式及组件技术的一种手段。
说到这里，我还特地跟了一句：“不要被热点名词所迷惑，即使它处在体系架构中的中间位置，也不应该把它称为 ‘中台’。”
“我个人觉得，你们把这个部门称为 ‘自定义服务事业部’ 更为贴切。”
说到这里，我特地停顿了下，喝了口咖啡，继续说。
“当然，刚才叙述的观点主要来源于我自己的实践经验，所以听上去会显得比较武断或片面，但中台战略的兴起在国内主要来自于阿里巴巴的中台战略思想。”
“在我们系统的演化过程中，我曾多次阅读 《企业IT架构转型之道：阿里巴巴中台战略思想与架构实战》这本书，在谈到构建业务中台基础的部分，有过这样一些描述，我觉得说的挺到位。”
说完，我打开阅读笔记给他看。
……
构建业务中台的基础 —— 共享服务体系。
松耦合的服务带来业务的复用，通过服务的编排助力业务的快速响应和创新。
反观企业需要通过ESB组件打通不同系统间的交互，实则是因为相关业务领域的业务和数据被以“烟囱式”方式建设的系统分割到了不同的系统中。
当越来越多的系统都采用自建“轮子”的方式满足自身系统对这部分业务的需求时，之前的这个服务慢慢就少有人问津，当有更好的服务出现或该服务完全满足不了当前业务发展的要求时，也就是这个服务离开历史舞台的时刻。
1、传统组织结构：我们可以将整个技术团队看做成一个组合精密的流水生产线，源源不断的业务需求进入到这条流水线后，经过流水线上各专业人员的贡献，最终将业务需求以系统的方式输出这条流水线。
