2.认识中台

1.数字化中台初步认识与建设策略

中台的定义

阿里对中台的定义:

中台是一个基础的理念和架构，我们要用中台的思想建设、联通所有基础服务，共同支持上端的业务。业务中台更多的是支持在线业务，数据中台则提供基础数据处理能力和很多的数据产品供所有业务方使用。即由业务中台、数据中台、算法中台等一起提供对上层业务的支撑；

ThoughtWorks对中台的定义:

中台是企业级能力复用平台；

总结

中台首先体现的是一种企业级的能力，它提供的是一套企业级的整体解决方案，解决小到企业、集团，大到生态圈的能力共享、业务联通和融合的问题，支持业务和商业模式创新。通过平台联通、业务和数据融合，为前台用户提供一致体验，更敏捷地支撑前台一线业务；
主要体现在这三个关键能力上:

• 对前台业务的快速响应能力;
• 企业级的复用能力;
• 从前台、中台到后台的设计、研发、页面操作、流程、服务和数据的无缝联通、融合能力；

传统企业中台的建设策略

企业中台业务能力建设一般会经历“分”和“合”两个过程:

• “分”的主要目标是通过业务领域边界划分和微服务拆分，建立稳定的单一职能的领域模型,让业务和应用具有更强的扩展和复用能力；
• “合”包括业务融合和数据融合。业务融合主要作用在前台，实现企业不同业务板块能力的联通、组装和整合，实现企业级业务流程的融合，提供—致的前台用户体验。而数据融合则主要作用在数据中台，实现企业不同业务板块数据的汇集、集成、智能分析和商业模式创新等，为企业前台业务提供统一的智能化数据服务；

如何实现前中后台的协同

阿里巴巴对前台、中台和后台职责的定位:

• 前台主要面向客户以及终端销售者，实现营销推广以及交易转换；
• 中台主要面向运营人员，完成运营支撑；
• 后台主要面向后台管理人员，实现流程审核、内部管理以及后勤支撑，比如采购、人力、财务和OA等系统；

2.企业中台能力框架

中台建设过程从根本上讲是企业自身综合能力持续优化和提升的过程，最终目标是实现企业级业务能力复用利不同业务板块能力的联通和融合。企业级的综合能力一般包含以下四种: 业务能力、数据能力、技术能力利组织能力:

• 业务能力主要体现为对中台领域模型的构建能力，对领域模型的持续演进能力，企业级业务能力的复用、融合和产品化运营能力，以及快速响应市场的商业模式创新能力；
• 数据能力主要体现为企业级的数据融合能力、数据服务能力以及对商业模式创新和企业数字化运营的支撑能力；
• 技木能力主要体现为对设备、网络等基础资源的自动化运维和管理能力，对微服务等分布式技术架构体系化的设计、开发和架构演进能力；
• 组织能力主要体现为一体化的研发运营能力利敏捷的中台产品化运营能力，还体现为快速建设自适应的组织架构和中台建设方法体系等方面的能力；

业务中台

业务中台的建设目标:

• 将可复用的业务能力沉淀到业务中台，实现企业级业务能力复用和各业务板块之间的联通和协同，确保关键业务链路的稳定高效，提升业务创新效能；
• 业务中台建设需优先解决业务能力重复建设和复用的问题。通过重构业务模型，将分散在不同渠道和业务场景(例如:互联网应用利传统核心应用)重复建设的业务能力，沉淀到企业级中台业务模型，面向企业所有业务场景和领域，实现能力复用和流程融合；

业务中台的实现方式:

• 在技术实现上: 中台的系统落地可以采用微服务架构。微服务是目前公认的业务中台技术最佳实现，可以有效提升业务扩展能力，实现业务能力复用；
• 在业务建模上，中台领域建模可以采用领域驱动设计(DDD)方法，通过划分业务限界上下文边界，构建中合领域模型，根据领域模型完成微服务拆分和设计；
• 业务中台可以面向前台应用提供基于APl接口级的业务服务能力，也可以将领域模型所在的微服务和微前端组合为业务单元，以组件的形式面向前台应用，提供基于微前端的页面级服务能力；

数据中台

数据中台与业务中台相辅相成，共同支持前台一线业务。数据中台除了拥有传统数据平台的统计分析和决策支持功能外，会更多聚焦于为前台一线交易类业务提供智能化的数据服务，支持企业流程智能化、运营智能化和商业模式创新，实现“业务数据化和数据业务化”；

技术中台

业务中台落地时需要有很多的技术组件支撑，这些不同技术领域的技术组件就组成了技术中台；
如API网关、开发框架、微服务治理、分布式数据库、数据处理组件等；

研发运营

研发运营的能力主要体现为研发运营一体化(DevOps)的协作能力和全链路的监控管理能力；
与传统架构相比，分布式微服务架构复杂的运行环境，会大大加剧定位和解决问题的难度，必须加强对微服务的监控；

云平台

云平台具有自动化的运营能力、全方位的安全管理能力、智能化的全链路监控能力，以满足基础资源利应用的弹性伸缩、软件的敏捷交付利自动化运维等要求；
如K8S、容器等云原生技术；

能力聚合

• 业务中台汇聚了企业大部分的核心业务能力，成为了企业的富能力层。基于业务职责单一原则，业务中台往往会更专注于本领域的业务能力，而不关心企业级前台应用到底如何进行企业级流程组合和编排。这种设计有利于保证业务中台领域模型和业务逻辑，不会因为前台业务需求的频繁变化而受到影响，从而保证中台领域模型的稳定；
• 在前台应用和业务中台之间增加一个能力聚合层，通过这一层实现跨业务中台的服务组合、编排、能力聚合服务发布和路由等功能。这些聚合了不同业务中台能力的聚合层服务是一种粗粒度的服务，可以作为企业级的整体解决方案，根据不同前台应用的功能和流程要求对多个中台的能力进行灵活的组合和编排，为不同渠道前台应用提供可复用的能力服务；

总结

业务中台解决企业业务能力可用和复用的问题，而数据中台则通过数据智能化解决业务能力如何用好的问题；

3.微服务设计为什么要选择DDD

遇到的问题

从很多微服务实践和企业最终目标来看，其实有时候微服务设计的重点不在于微服务的大小，也不在于拆分出多少个微服务，而是在于微服务内外部的边界是否清晰，这些边界是否进行了有效隔离，以及这些微服务上线后能否随着业务的发展轻松实现业务模型和微服务架构的演进。所以，在微服务设计时，找们要考虑微服务拆分的大小，也要关注微服务内部的逻辑边界；
DDD的核心思想是从业务视角出发，根据限界上下文边界划分业务的领域边界，定义领域模型，确定业务边界。在微服务落地时，建立业务领域模型与微服务代码模型的映射关系，从而保证业务架构与微服务系统架构的—致性；

DDD划分边界

DDD包括战略设计和战术设计两部分，它们分别从不同的视角出发，完成领域建模和微服务的拆分和设计:

• 战略设计是从业务视角出发，划分业务的领域边界，建立基于通用语言和业务上下文语义边界的限界上下文，构建领域模型。而限界上下文就可以作为微服务拆分和设计的边界；
• 战术设计则是从技术视角出发，侧重于对领域模型的技术实现，按照领域模型完成微服务的开发和落地。在战术设计中会有聚合、聚合根、实体、值对象、领域服务、领域事件、应用服务和仓储等领域对象，这些领域对象会以代码的形式映射到微服务中，完成设计和系统落地；

DDD构建步骤

分三步来构建领域模型和划分微服务的边界:

• 第一步，在事件风暴中根据场景分析，梳理业务过程中的用户操作、领域事件以及与外部的依赖关系等，找出哪些业务对象产生了这些业务操作或行为，并根据这些业务对象梳理出实体等领域对象；
• 第二步，根据领域实体之间的业务关联性，找出聚合根，将业务紧密相关的、相互依赖的实体组合形成聚合，确定聚合中的聚合根、值对象和实体。同一个限界上下文内，聚合之间的边界是微服务内部的第一层边界，这些聚合在同一个微服务实例内运行。这个边界是一个逻辑边界；
• 第三步，根据业务语义环境及上下文边界等因素，将一个或者多个聚合划定在一个限界上下文内，构建领域模型。限界上下文之间的边界是第二层边界，这一层边界可能就是未来微服务的边界。不同限界上下义内的领域模型的业务逻辑，被隔离在不同的微服务实例中运行，它们在物理上是相互隔离的，所以这一层边界是物理边界；

4.DDD、中台和微服务的关系

中台是抽象出来的业务模型，微服务是业务模型的系统实现，DDD作为方法论可以同时指导中台业务建模和微服务建设，三者相辅相成，完美结合；

中台的本质

• DDD划分为三类不同的子域，它们分别是: 核心子域、支撑子域利通用子域；
• 通过领域划分利进一步的子域划分，我们就可以区分不同子域在企业内的功能属性和重要性，进而采取不同的资源投人利建设策略。—般来说，企业战略投人的重点是核心子域；
• 中台的本质其实就是提炼各个业务板块的共同需求，进行业务和系统抽象，形成通用的、可复用的业务模型。打造成组件化产品，供前台部门使用；

中台业务建模

中台业务抽象的过程实际上就是业务建模的过程，对应DDD的战略设计。中台系统抽象的过程就是微服务的设计过程，对应DDD的战术设计；

步骤

采用DDD方法的中台领域建模大致可以分为如下五个步骤:
DDD战略设计涵盖了第一步到第四步，主要包括: 将业务领域分解为不同属性的中台，将中台区分为核心中台和通用中台，在中台这个业务边界内完成领域建模，构建中台业务模型；
DDD战术设汁主要在第五步，将领域模型作为微服务设计的输人，映射为微服务就完成中台的系统落地了；

• 第一步，按照核心业务流程节点(通常适用于核心子域)或者功能属性和集合(通常适用于通用子域或支撑子域)，将业务领域细分为多个中台，再根据中台的功能属性或重要性归类到核心中台或通用中台。核心中台设计时要考虑企业战略发展和核心竞争力以及多渠道核心能力复用，通用中台要站在企业高度进行抽象和标准化设汁，面向所有业务领域实现能力共享和复用；
• 第二步，选取中台所在的业务领域，运用事件风暴方法，通过用例分析、业务场景分析或用户旅程分析等方法，找出业务领域的实体、聚合和限界上下文。依次完成各个中台的领域分解和领域建模；
• 第三步，在确定主领域模型后，以主领域模型为基准，逐—扫描其他中台领域模型，根据名称或业务动作的相似性等条件，检查是咨存在重复的领域模型或领域对象，或者游离于主领域模型之外，但与主领域模型同属于一个限界上下文的领域对象。将这些重复或游离的领域对象，合并到主领域模型提炼并重构主领域模型，完成领域模型设计；
• 第四步，选择其他领域模型重复第三步，直到所有领域模型完成领域对象比对和领域逻辑重构；
• 第五步，将领域模型作为微服务设计的输人，完成微服务的拆分和设计，完成微服务落地；