中台
中台这一概念，最近在国内大热。阿里、腾讯、百度、京东、美团、滴滴等一众互联网巨头，从去年到今年，接连开始组织架构的调整，意图建设中台。也有很多人认为，中台并不是解决一切问题的法宝，小公司不需要用中台，只有发展到一定规模的公司才需要中台。是不是要有中台？中台适合什么阶段/规模的公司？是一个可以值得去讨论的问题。
1.什么是中台，到底要解决什么问题？
这个最早由阿里在2015年提出的“大中台，小前台”战略中延伸出来的概念，灵感来源于一家芬兰的小公司Supercell——一家仅有300名员工，却接连推出爆款游戏，是全球最会赚钱的明星游戏公司。 这家看似很小的公司，设置了一个强大的技术平台，来支持众多的小团队进行游戏研发。这样一来，他们就可以专心创新，不用担心基础却又至关重要的技术支撑问题。恰恰是这家小公司，开创了中台的“玩法”，并将其运用到了极致。
Supercell是如何成功的？
最好的团队创造最好的游戏， 将一个游戏公司，按照一个专业运动队的方式来管理。在这种模式下，创始人和管理层的唯一使命是获得最好的人才，为他们创造最好的环境，给他们自由和信任，帮助他们摆脱困境，让公司成为一个最好的人才可以产生最大影响的地方
完全颠倒的管理结构，300人的团队被分成若干个小团队，5-7个游戏开发者组成一个小团队，开发自己的游戏，以最快的速度推出公测版，检测游戏受用户欢迎的情况。这些小团队又被称为“细胞”(cell)，Supercell则是这些细胞的集合，这也是Supercell公司名的由来。
小而精的团队 ，一个“细胞”的核心通常只有5人，最多也不会超过7人。员工虽少但精，还有充分的自由度。 团队小意味着试错成本不会太高，时间和方向也可以即使调整和转变，以满足高速变化的市场需要，对战机的把握更加敏捷，一旦发现正确目标，就可以全力投入扩大战果。 他们会给公司内部所有人分享所有的信息。每天早上，所有人都会收到邮件，包括每款游戏的详细数据，工作环境非常透明化。游戏表现好，所有人都看得到，如果表现不行，所有人也都知道。这样一来，会形成压力比较大的工作环境，但对于合适的人来说，这也是他们努力的动力。
扼杀不成功的项目， 研发团队自己决定创意和想法，但他们也同时给自己的项目设定目标。比如一个新项目在测试之前，团队就要设定一个指标，比如玩家留存、参与度，然后把这个目标告诉全公司的人。游戏进入测试之后，如果达不到指标，它就会被取消，不管团队成员多么热爱都不能阻止。 在Supercell，失败从来不是可耻的记录，而反倒是一种进步的动力。独特的“庆祝失败”根植于其企业文化之中，潘纳宁认为：“我们是在从失败中吸取教训的基础上建立了这家公司。失败得越快，我们学习得越快，也会变得越好”。
所谓“中台”，其实是为前台而生的平台，它存在的唯一目的就是更好的服务前台规模化创新，进而更好的服务用户，使企业真正做到自身能力与用户需求的持续对接
2.优势和坏处？
中台某种程度上是为前台而生的！ 为了业务的敏捷，创新！有下面三个特征：
敏捷 业务需求变化快，变更以天甚至更短的频率计算，一个单体大型应用，庞大的开发团队对单一应用的变更变得越来越困难。将大应用变为多个小的应用组合，才能适应外部的快速变化，实现业务的敏捷。
解耦 随着业务的发展，业务系统之间的交互通常会变得越来越复杂。一个功能的修改可能会影响很多方面。只有将需要大量交互的功能独立，从应用中拆解出来，这样可以使得应用之间耦合度大幅下降。
复用 一些公共的能力通过复用，大大提高了开发效率，避免了重复建设。同时使得数据和流程可以集中得以管理和优化。
那么中台应该包含些什么东西？中台通常可以分为三个层面： 业务层面，数据层面和技术底层。
业务中台 业务服务将业务的公共需求组合成服务，比如电商公司，客户，商品，物流，支付就是公共需要，比如汽车制造商，用户，车辆，订单，交付都是公共需求。将这些公共业务组合成统一的业务服务，供各个业务单元使用。
数据中台 数据服务数据时代，业务中越来越依赖于数据，包含：数据的收集，数据处理，数据算法和分析，报表，以及数据的治理。
技术中台 基础服务通常是底层的服务，面向技术。这些底层技术包括：安全认证，权限管理，流程引擎，门户，消息，通知等等。这些组件通常与业务关联度不大，属于每个应用都需要使用的功能。
现阶段，大多数提出中台战略或是建设大中台的公司，大多都有类似的困境。业务高速发展多年，许多问题积重难返或者大量在解决“重复造轮子”的问题，中台这个概念，很多情况下是因为契合了大公司业务的发展的情况，而被大家广泛认可。对于很多中小公司，当他们走出生存困境，进入到高速发展阶段时，会遇到很多的问题，但大概率会遇到的一个问题是，过往的业务模型，产品能力很有可能没法完全承接住大规模用户增长带来的压力。
3 如何来构建中台？
中台的建设不是那么件轻松的事情。首先要建立“中台“配套的相关管理机制，其次是建立应用架构，从相对容易的基础共享服务开始，到定制与业务贴合的业务中台。在建立中台的过程中，需要配套中台运行的后台基础架构。中台的建设可以总结为五步走。
建立合理的管理机制 中台的建立，切忌做成项目制，中台需要使用产品管理的方式来对待。这是因为中台对外提供的服务需要不停的迭代，适应业务的需求，否则经过一段时间，前台因为中台提供的服务固化，只好自己新建一个服务来满足业务需求，逐渐不使用中台提供的公共服务。 对于中台产品来说，必须思考的问题是，这个功能在现在或者将来能满足多少业务场景？如果将来有新的业务出现，是不是能够复用？或者说，需要做多大的调整才可以复用？甚至于，这个功能有没有可能对外输出，提供SaaS化的服务。
搭建适合企业的应用架构 企业和阿里巴巴不同，阿里巴巴基本上都是C端应用，电商、文娱、消费。业务系统都是自己开发。企业则历史包袱重，自主开发能力不强，既有购买的商品化软件，又有自行开发的系统。比如，制造企业既有后端的SAP ERP，PLM，MES，WMS等系统，这些年又产生了面向外部的电商，客户服务，营销服务等前端系统。前端系统由于市场需要变化快，要求系统迭代速度以周甚至天计算，而后台的传统应用，变更和迭代通常以月甚至年来计算。
提供基础共享服务 基础共享服务是面向技术层面的基础公共共享服务，因为大部分服务就是集成功能，因此也可以称为“集成中台”。大致有如下的共享公共服务：
4. 数据中台
进入到数据时代（DT），数据的重要性越来越被企业认知。对数据的收集，分析计算，深度学习，并转让为企业的核心竞争力。
5. 业务中台
业务中台每一个企业都是不同的，它是高度个性化的，无法通过直接购买获得，因为它与业务密切相关。业务中台需要长期的沉淀，抽象和归纳。打造一个业务中台绝不是一朝一夕的事情。
微服务定义
什么是微服务？
维基上对其定义为：一种软件开发技术- 面向服务的体系结构（SOA）架构样式的一种变体，它提倡将单一应用程序划分成一组小的服务，服务之间互相协调、互相配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据上下文，选择合适的语言、工具对其进行构建。
DDD定义
wiki释义：
领域驱动设计（英语：Domain-driven design，缩写 DDD）是一种通过将实现连接到持续进化的模型[1]来满足复杂需求的软件开发方法。领域驱动设计的前提是：
把项目的主要重点放在核心领域（core domain）和域逻辑
把复杂的设计放在有界域（bounded context）的模型上
发起一个创造性的合作之间的技术和域界专家以迭代地完善的概念模式，解决特定领域的问题
领域驱动设计是一种由域模型（墙裂推荐@阿白 的域模型系列）来驱动着系统设计的思想，不是通过存储数据词典(DB表字段、ES Mapper字段等等)来驱动系统设计。领域模型是对业务模型的抽象，DDD是把业务模型翻译成系统架构设计的一种方式。
三者关系
我认为，要想应用 DDD，首要任务就是要吃透 DDD 的核心设计思想，搞清楚 DDD、微
服务和中台之间的关系。中台本质是业务模型，微服务是业务模型的系统落地，DDD 是一
种设计思想，它可以同时指导中台业务建模和微服务设计，它们之间就是这样的一个铁三角
关系。DDD 强调领域模型和微服务设计的一体性，先有领域模型然后才有微服务，而不是
脱离领域模型来谈微服务设计。
其次，就是通过战略设计，建立领域模型，划分微服务边界。这步是关键，你可以借助专栏
中的一些经验。
最后，通过战术设计，我们会从领域模型转向微服务设计和落地。此时，边界清晰、可持续
演进的微服务架构雏形就在你面前了。
遵循以上过程，这门课的设计思路也就诞生了。
