一、数字化转型
数字化转型是企业能力全面体系化，系统化，数据化提升的过程，这种提升包括了技术能力，业务能力，组织架构合理性等多方面的提升。
而随着多年来海量高频业务的发展，技术也在推动着持续进步，并且越来越多的技术方案趋向成熟，类似于阿里巴巴，腾讯，美团等，所有业务都已上云，并且在整套分布式架构上，无论是流量控制层，还是微服务治理上，都有了自己成熟的解决方案并对外开源，如今许多开发人员对技术的使用，无非是成为一名API调用师，成熟的技术解决方案免去了底层的很多研发工作。
技术能力相比，项目实施过程中如何分离技术和业务的复杂度，成了技术和业务侧都比较麻烦的问题，这个问题会影响业务快速适应和响应日益增长的市场需求，因此，建立企业级可复用的业务模型构建能力，数据智能驱动产品运营能力，以及Devops如何更快速高效的支持应用迭代，都会在企业数字化转型建设中占据更主要的位置，成为可能制约企业数字发展的瓶颈。
纵观N多企业对数字化转型的落地，无非从如下几个方面：
1、提升技术能力，研发投入，完成集中式架构向分布式架构的转型
2、解耦应用复杂度，完成微服务架构的转型
玩过微服务的同学都知道，微服务职责单一，业务比较聚焦，比较适合构建敏捷小而精的团队进行快速迭代。同时应用包较小，方便部署和弹性拓展，更方便的运维
3、从IT重复建设到中台战略的过渡，建立企业级可复用的业务模型构建能力
大公司中由于部门众多，科技子公司的产品常常不能满足所有业务的需求，迭代更新慢，所以很多非科技的子公司也有自己的科技部门，存在严重的IT重复建设，因此通过实施企业中台战略，通过划分业务边界构建领域模型，将可复用的业务能力沉淀到中台，实现业务的组合，复用。
4、传统PC向移动应用转型
移动应用的出现改变了用户的消费行为和使用习惯，企业可在指定战略时，将关键资源从传统PC端逐步转移到移动端，打造和运营一个用户体验良好的移动平台
5、建立与中台适配的组织架构和管理模式，提高组织能力
中台建设要与组织架构优化同步进行。企业IT重复建设和业务割裂往往来源于部门的边界墙，各自形成标准和规范，不利于降低企业成本。而中台的建设可以极大的提高组织的战斗力，在技术和业务上形成统一的规范和标准，打破组织孤岛，需要“一把手”级别的人去推动和努力。
二、什么是中台
中台和我们平时理解的平台是有差异的，中台来源于平台的共享，联通，融合，统一和创新。区别于共享平台，很多企业的共享平台，也服务了内部很多业务部门，但是更多的是基于业务部门的需求，去做定制化开发，或者为了某个部门的小小需求，揉进了一个99%用户都不会使用的功能，长此以往，会使整个平台变得十分鸡肋和笨重，对于用户来说，接触平台的时候冒出来很多他不关心的边缘功能和名词，使用起来体验十分不好，并且学习成本的提高带来了心累。
目前的一些企业，虽然已经将公共服务能力以HTTP API的友好形式对外提供共享服务，解决IT重复建设的问题，但实际没有与其他平台实现从前端到后端的业务流程，数据整合，没有将企业完整的核心业务链路作为企业级解决方案考虑，依然存在着组织和平台孤岛。
中台是企业级能力复用的平台。
- 中台一般包含业务中台，数据中台，技术中台，AI中台，移动中台
- 中台关注企业级业务和流程整体好用，而不是满足所有业务部门个性化需求的平台
- 中台共享，联通，融合，统一和创新所有基础服务，共同支撑构建其之上的业务
- 要具备对业务的快速响应能力和可拓展能力
三、中台能力框架
中台架构的综合能力，主要要包括业务建模能力，数据能力，技术能力，组织能力，运营能力以及核心的能力聚合，如图
业务建模能力：
主要体现为对业务领域模型的构建能力，持续演进能力，形成企业级复用的业务能力，业务中台承载了企业的核心关键业务，以电商系统为例，业务中台可以通过领域驱动设计（DDD）方法，划分领域的上下文边界，构建领域模型，根据模型完成微服务
数据能力：
数据中台和业务中台相辅相成，主要来源于数据趋势的几点变化
1、数据中台一般包括数据建模，采集，清洗，加工，治理等，这些技术解决业务问题的能力越来越强
2、随着万物互联的趋势，数据来源变得多元化，从单一的业务数据向复杂的多源数据转变，从以遵循范式的结构化数据为主，向反范式，结构化与非结构化多种模式混合的方向转变
3、数据智能应用的广泛应用，通过AI对数据做分析，帮助提升用户体验，营销的精准程度，从而做出正确的导流方向
数据中台的大部分数据来自于业务中台，经过数据建模，分析和训练后，将加工后的数据返回业务中台使用，或者直接以API或数据类应用的形式面向前台应用。中台的建设，可以消除不同业务板块核心业务之间的数据孤岛
技术能力：
中台建设的最佳落地实践是微服务架构，微服务架构方便对业务的拆解和划分界限，有效应对海量业务的拓展，保证系统可用性，因此业务中台还需要依赖于技术中台的底座。
技术中台主要包含微服务框架，构建于框架之上的服务治理，中间件，数据库和解决多区域，多中心的分布式解决方案能力等。
组织能力：
组织能力本质上是企业内组织，人与中台能力的结合，中台的能力最终都需要落到组织能力上。
运营能力：
运营能力的核心即是Devops能力的建设，Devops的自动化运维程度越高，研发和运维的协作能力，处理问题与故障能力，解决环境与环境直接差异性的能力，全链路监控告警的能力，都会得到显著的提升
聚合能力：
基于职责单一原则，业务中台更多专注于各个领域的业务能力，这时需要一个介于前台和中台之间的能力聚合层，根据前台不同应用功能和流程对业务中台多个领域的能力进行编排，聚合，提供可复用的企业级整体解决方案。
聚合层也以微服务的架构落地，但他不完成具体的业务逻辑，只进行服务编排和聚合。
一、AKF拓展立方体
中台本质上是企业的业务模型，中台领域模型落地时需要架构的支撑。
无论是最早的阿里巴巴中台战略的落地，还是其他企业的实施方案来看，目前中台落地的技术手段和架构，最佳实践就是微服务架构，微服务架构有利于服务的拆分和拓展，以支持日益增长的业务需求，《架构真经》的书里提出了微服务的AKF拓展立方体。
现代社会的经济，建立在可扩展可伸缩的基础架构之上，尤其是互联网经济，只有达到一定规模后才能盈利，如此便要求系统是可扩展，可伸缩的
X轴：水平复制微服务实例
Z轴：将微服务实例分区，即可以划分区域（北京，上海）实现拓展
Y轴：将微服务以功能模块的形式进行拆分
其中，X，Z轴的实现是已有成熟可靠的方案，但没有解决日益增长的开发和业务的复杂性，Y轴就是为解决业务复杂性而生，通过领域建模，划分不同业务领域的界限，形成各自独立的微服务能力，但Y轴如何按照功能模块进行拆分，一直没有一个清晰的界限和方法论，而领域驱动设计的方法论，可以很好的解决这个问题。
二、微服务为什么需要DDD？
微服务架构将服务作为模块化的单元，模块化是功能分解的基础，所有形式的模块化要大体遵循如下两个原则：
1、小而专注，功能内聚——按业务边界来确定服务的边界
2、自治性——避免多个服务相互依赖，一起部署，有自己独立的数据库等
大多数人对微服务的理解还停留分解上，停留在容器技术的发展带来了服务拆分上
《微服务架构设计模式》的书作者Chris Richardson告诉我们，微服务的本质是服务的分解和定义，微服务架构告诉我们应该按业务边界去定义服务的边界，但是没有告诉我们如何识别和定义业务边界
DDD诞生于2003年Eric Evans出版的《领域驱动设计》，DDD的核心思想是从业务视角出发，根据限界上下文边界划分业务的领域边界，定义领域模型，确定业务边界。在微服务落地时，建立业务领域模型与微服务代码模型的映射关系，从而保证业务架构与微服务系统架构的一致性。
