网站可扩展架构设计—

从公众号转载，关注微信公众号掌握更多技术动态

---------------------------------------------------------------

一、中台简介

1.传统项目架构的痛点

(1)重复造轮子

各项目相对独立，许多项目在重复造轮子，让项目本身越来越臃肿，也使开发效率越来越低。

(2)前台和后台发展速度不同

前台：由各类前台系统组成的前台业务平台。每个前台系统都是一个用户触点，大多是企业最终用户直接使用的系统，是企业与最终用户的交点。例如用户直接使用的网站、手机App、微信公众号、小程序等都属于前台范畴。前台不仅仅是指前端，它还包含和前端配套的服务端。
后台：由后台系统组成的后端支撑平台。每个后台系统一般管理了企业的一类核心资源（数据 + 计算），例如财务系统、产品系统、客户管理系统、仓库物流管理系统等，这类系统构成了企业的后台。

后台管理的往往是企业的关键核心数据，考虑到企业安全、审计、合规、法律等限制，这样的系统也往往⽆法被前台系统直接使用，或是受到各类限制⽆法快速变化，不能⽀持前台快速的业务创新需求。此时的前台和后台就像是两个不同转速的齿轮，前台由于要快速响应前端用户的需求，讲究的是快速迭代创新，所以要求转速越快越好；而后台由于面对的是相对稳定的企业核心后端资源，而且往往系统陈旧复杂，甚至还受到法律法规、审计等相关合规约束，一般是追求稳定至上，越稳定越好，转速也自然是越慢越安全。

2.中台如何解决

为了解决上述痛点，提高开发效率而整合出的中间组织，为所有项目提供公共资源，这个中间组织就是“中台”。中台的架构思想不仅影响项目结构，也影响了研发团队的组织形式。

中台将早已臃肿不堪的前台系统中稳定通用的业务能力“沉降”到中台层，为前台减肥，恢复前台的响应力；又可以将后台系统中需要频繁变化或是需要被前台直接使用的业务能力“提取”到中台层，赋予这些业务能力更强的灵活度和更低的变更成本；或者干脆直接对于后台进行中台化改造，通过配置化、自助化、白屏化等形式为后台加速，从而为前台提供更强大、更迅捷、更易用的支援。

3.中台本质

(1)企业级能力复用平台

①“企业级”

“企业级”定义了中台的范围(这里的企业级不是说难度而是指范围。企业级也不一定就是一个企业的范围，甚至可以是跨企业)，它提供的是一套企业级的整体解决方案，解决小到企业、集团，大到生态圈的能力共享、联通和融合问题，中台一个企业只需要一个(至少包含多条业务线或服务多个前台产品（团队）)。需要充分考虑未来架构规划对于战略的影响，回归到业务上，也和过去做系统完全不同，面对的将是企业的业务全貌，甚至是那些未来才会出现的，现在还不知道长什么样子的潜在的创新业务。

②“能力”

“能力”定义了中台的主要承载对象，能力的抽象解释了各种各样中台的存在；企业的能力可能包含多个维度，常见的例如计算能力，技术能力，业务能力，数据能力，AI能力，运营能力，研发能力……其中大部分的能力还可以继续细化和二次展开，从而形成一张多维度的企业能力网。可以说，中台就是企业所有可以被「多前台产品团队」复用能力的载体。这里有一个经常碰到的问题，就是对于某一家企业来讲，你说了有这么多种不同类型的能力，到底哪些能力才是我们企业需要的？哪些是值得中台化的？优先级又怎么划分？通过一系列Workshop，从业务、数据、技术等多个方面切入，通过一系列方法，结合企业愿景，市场定位和数字化现状，跨越多条业务线，试图将企业需要的能力和可复用的能力识别出来，并为落地做好规划和准备。

③“复用”

“复用”定义了中台的核心价值，传统的平台化对于易复用性和前台的用户体验并没有给予足够的关注，中台的提出和兴起，让人们通过可复用性将目光更多的从平台内部设计转换到平台对于前台业务的支撑上；只有能复用的能力才有意义做中台。

「复用」是中台更加关注的目标；
「可复用性」和「易复用性」是衡量中台建设好坏的重要指标；
「业务响应力」和「业务满意度」也才是考核中台建设进度的重要标准。

而实现更好的复用，常常从两个方向做改进：

一方面将更高抽象（例如业务模式级别）的通用业务逻辑通过抽象后下沉到中台，这样前台就会更轻，学习成本和开发维护成本更低，越能更快的适应业务变化；缺点是，抽象级别越高，越难被复用，需要架构师对于各业务有深入的理解和非常强的抽象能力。

另一方面就是通过对于中台能力的SaaS化包装，减少前台团队发现中台能力和使用中台能力的阻力，甚至通过自助式（Self-Service）的方式快速定位和使用中台能力。目前很多企业在尝试的内部API集市或是数据商店就是在这方面的努力和尝试。

④“平台”

“平台”定义了中台的主要形式，区别于传统的应用系统拼凑的方式，通过对于更细粒度能力的识别与平台化沉淀，实现企业能力的柔性复用，更好地支撑前台业务。

中台首先体现的是一种企业级的能力，

有了完善的中台，就可以通过有限而比较固定的基础业务，来满足无限而快速变化的上层业务场景了。从业务角度来看，中台收敛了业务场景，统一了业务规则；从系统角度看，中台相当于操作系统，对外提供标准接口，屏蔽了底层系统的复杂性；从数据角度看，中台收敛了数据，比如使用同一套订单数据模型，让所有渠道的订单使用相同的订单模型，所有订单数据落到同一个订单库。

做中台建设的时候，一定是跳出单条业务线、站在企业整体视角来审视业务全景，寻找可复用的能力进行沉淀，从而希望通过能力的复用一方面消除数据孤岛、业务孤岛，一方面支撑企业级规模化创新，助力企业变革，孕育生态。虽然中台的建设过程虽然可以自下而上，以点及面。但驱动力一定是自上而下的，从全局视角出发的，并且需要一定的顶层设计。这也解释了为什么在企业中推动中台建设的往往都是跨业务部门，例如CIO级别领导或是企业的战略规划部门，因为只有这些横跨多条业务线的角色和组织，才会经常去反思与推动企业级的能力复用问题。

(2)明确中台作用

①做之前需要明确做中台的目标，解决什么问题

你的规模大到足够消化中台吗？
中台能给你带来什么商业价值？

中台既不是一套软件，也不是一套服务器，而是一种理念、一套方法论。第三方公司的销售为了拿下客户，也会夸大中台的效果。云徙前技术骨干周宏告诉 36 氪，他发现，销售去客户那讲 PPT 的时候，“什么都承诺，什么东西都有，”造成一种中台能“包治百病”的感觉。这就造成了一个极为吊诡的现象：一时间大家都在说中台，似乎什么都可以往“中台”里装。有业务中台、数据中台、技术中台、安全中台、AI中台……从来没有一个“风口”，像中台这样说不清、道不明。

②中台实际作用

以用户为中心的持续规模化创新，是中台建设的核心目标。企业的业务响应能⼒和规模化创新能力，是互联⽹时代企业综合竞争⼒的核⼼体现。平台化包括中台化只是帮助企业达到这个目标的⼿段，并不是⽬标本身。
中台(⽆论是技术中台、业务中台还是组织中台)的建设根本上是为了解决企业响应⼒困境，弥补创新驱动快速变化的前台和稳定可靠驱动变化周期相对较慢的后台之间的⽭盾，提供⼀个中间层来适配前台与后台的配速问题，沉淀能⼒，打通并顺滑链接前台需求与后台资源，帮助企业不断提升用户响应⼒。

4.中台和平台的区别

中台是支持多个前台业务且具备业务属性的共性能力组织，平台是支持多个前台或中台业务且不具备业务属性的共性能力。

比如数据存放在Hadoop可以称为大数据平台，中台使得数据不再是各前端业务独立管理，而是通过统一的团队在数据标识、指标、数据仓库等方面实现了跨业务的整合

中台还是平台与所在的业务环境相关。同样的能力对A业务来说可能具备业务属性从而是中台，但对B业务来说没有业务属性从而是平台。比如说IDC建设和运维对AWS来说可谓至关重要的业务中台，而对绝大多数企业来说只能说是平台。PaaS平台对SaaS厂商来说是业务中台，但对绝大多数企业来说也只能说是平台。

所以，不具备业务属性的能力，即便是共性的，即便有一个专职的部门在做，即便对业务非常重要，也不能称之为中台，而还是应该称之为平台。因此，应该说所有中台都是业务中台，没有别的类型的中台。数据中台、搜索中台、内容中台、零售中台等等，都是特定形式的业务中台，也还是业务中台。

二、中台的使用

1.中台的分类

(1)业务中台

把各项目的共同业务进行下沉，整合成通用的服务。业务中台需要具体承载支撑业务开展的必要业务元素，封装着为了保障业务可以顺利开展需要解决的必要问题空间的解决方案。

(2)技术中台

避免重复造轮子，提供通用的底层框架、引擎、中间件。「技术中台」有点像编程时的适配层，起到承上启下的作用，将整个公司的技术能力与业务能力分离，并以产品化方式向前台提供技术赋能，形成强力支撑。

(3)数据中台

抽象数据能力的共性形成通用数据服务能力，为各个项目进行数据分析和采集。

从后台及业务中台将数据流入，完成海量数据的存储、计算、产品化包装过程，构成企业的核心数据能力。比如海量数据进行采集、计算、存储、加工的一系列技术集合，包括数据模型、算法服务、数据产品、数据管理等等，和企业的业务有较强的关联性，是企业独有的且能服用的。

数据中台通过对于业务数据的二次加工，并反馈回业务中台，为业务进行数据和智能方面的赋能。

(4)算法中台

为各项目提供算法能力

(5)研发中台

软件开发是一项工程，涉及到管理、流程、测试、团队协作等方面。如何将企业的开发流程最佳实践沉淀成可重用的“能力”，从而助力创新性应用的快速开发迭代，也是我们看到的很多企业正在做的事情，我们可以管这种关注与开发效能管理的平台叫做研发中台。如果说技术中台为前台应用提供了基础设施重用的能力，那研发中台就为前台应用提供了流程和质量管控以及持续交付的能力。

2.适用场景

从0到1阶段：没有必要搭建中台，首要目的是生存，市场价值验证，野蛮生长最适合
从1到N阶段：适合搭建中台，价值已被认可，项目复杂度不是特别高，搭建中台为后续快速迭代试错做准备
从N到N+1阶段：搭建中台势在必行，企业规模大，产品、服务、部分错综复杂。为了长期发展，搭建中台，避免以后越来越难以维护

什么情况下别做中台：业务还没成型、没有相近的多个业务、人员能力不足——如果一个企业奔着中台做中台，就是死。

3.如何实现前中后台的协同？

企业级能力往往是前中后台协同作战能力的体现。如果把业务中台比作陆军、火箭军和空军等专业军种的话，它主要发挥战术专业能力。前台就是作战部队，它需要根据前线的战场需求，对业务中台的能力进行调度，实现能力融合和效率最大化。而数据中台就是信息情报中心和联合作战总指挥部，它能够汇集各种数据、完成分析，制定战略和战术计划。后台就是后勤部队，提供技术支持。

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

(1)前台

传统企业的早期系统有不少是基于业务领域或组织架构来建设的，每个系统都有自己的前端，相互独立，用户操作是竖井式，需要登录多个系统才能完成完整的业务流程。

中台后的前台建设要有一套综合考虑业务边界、流程和平台的整体解决方案，以实现各不同中台前端操作、流程和界面的联通、融合。不管后端有多少个中台，前端用户感受到的就是只有一个前台。

在前台设计中我们可以借鉴微前端的设计思想，在企业内不仅实现前端解耦和复用，还可以根据核心链路和业务流程，通过对微前端页面的动态组合和流程编排，实现前台业务的融合。前端页面可以很自然地融合到不同的终端和渠道应用核心业务链路中，实现前端页面、流程和功能复用。

(2)中台

传统企业的核心业务大多是基于集中式架构开发的，而单体系统存在扩展性和弹性伸缩能力差的问题，因此无法适应忽高忽低的互联网业务场景。而数据类应用也多数通过 ETL 工具抽取数据实现数据建模、统计和报表分析功能，但由于数据时效和融合能力不够，再加上传统数据类应用本来就不是为前端而生的，因此难以快速响应前端一线业务。业务中台的建设可采用领域驱动设计方法，通过领域建模，将可复用的公共能力从各个单体剥离，沉淀并组合，采用微服务架构模式，建设成为可共享的通用能力中台。同样的，我们可以将核心能力用微服务架构模式，建设成为可面向不同渠道和场景的可复用的核心能力中台。业务中台向前台、第三方和其它中台提供 API 服务，实现通用能力和核心能力的复用。

在将传统集中式单体按业务职责和能力细分为微服务，建设中台的过程中，会产生越来越多的独立部署的微服务。这样做虽然提升了应用弹性和高可用能力，但由于微服务的物理隔离，原来一些系统内的调用会变成跨微服务调用，再加上前后端分离，微服务拆分会导致数据进一步分离，增加企业级应用集成的难度。如果没有合适的设计和指导思想，处理不好前台、中台和后台的关系，将会进一步加剧前台流程和数据的孤岛化、碎片化。

数据中台的主要目标是打通数据孤岛，实现业务融合和创新，包括三大主要职能：

一是完成企业全域数据的采集与存储，实现各不同业务类别中台数据的汇总和集中管理。
二是按照标准的数据规范或数据模型，将数据按照不同主题域或场景进行加工和处理，形成面向不同主题和场景的数据应用，比如客户视图、代理人视图、渠道视图、机构视图等不同数据体系。
三是建立业务需求驱动的数据体系，基于各个维度的数据，深度萃取数据价值，支持业务和商业模式的创新。

相应的，数据中台的建设就可分为三步走：

第一步实现各中台业务数据的汇集，解决数据孤岛和初级数据共享问题。
第二步实现企业级实时或非实时全维度数据的深度融合、加工和共享。
第三步萃取数据价值，支持业务创新，加速从数据转换为业务价值的过程。

数据中台不仅限于分析型场景，也适用于交易型场景。它可以建立在数据仓库或数据平台之上，将数据服务化之后提供给业务系统。基于数据库日志捕获的技术，使数据的时效性大大提升，这样就可以为交易型场景提供很好的支撑。综上，数据中台主要完成数据的融合和加工，萃取数据业务价值，支持业务创新，对外提供数据共享服务。

(3)后台

那对于后台，为了实现内部的管理要求，很多人习惯性将这些管理要求嵌入到核心业务流程中。而一般来说这类内控管理需求对权限、管控规则和流程等要求都比较高，但是大部分管理人员只是参与了某个局部业务环节的审核。这类复杂的管理需求，会凭空增加不同渠道应用前台界面和核心流程的融合难度以及软件开发的复杂度。

在设计流程审核和管理类功能的时候，可以考虑按角色或岗位进行功能聚合，将复杂的管理需求从通用的核心业务链路中剥离，参考小程序的建设模式，通过特定程序入口嵌入前台 APP 或应用中。

管理需求从前台核心业务链路剥离后，前台应用将具有更好的通用性，它可以更加容易地实现各渠道前台界面和流程的融合。一个前台应用或 APP 可以无差别地同时面向外部互联网用户和内部业务人员，从而促进传统渠道与互联网渠道应用前台的融合。

三、中台建设方法论

1.产品化思维建设中台

(1)现有组织架构的困局

无论是以传统行业为代表的直线职能型组织，还是以互联网为代表的事业部（产品型）组织，亦或是各种组合变种（例如最常见的矩阵组织结构），我们发现在中台建设的演进过程中都会或多或少陷入到同样的问题。

所以，问题不在于企业原本是哪类的组织结构，问题在于中台团队本身的定位。

在两种组织结构的推演中，因为Shared Servie（共享服务中心）的组织概念历史悠久，深入人心。所以大多默认会将中台团队一开始就定位成一个内部的共享职能团队。

中台团队被定位成一个共享职能团队，中台团队与前台团队之间的关系是服务和被服务的关系，这才是问题的关键。

因为中台是一个共享服务团队，与前台是服务与被服务的关系。那自然前台出钱，中台团队为其提供服务就是天经地义的事情，正所谓“拿人钱财替人消灾”。

这时候就会出现两种情况：

一种情况是，因为中台建设的复杂性和长期性，导致短期无法满足前台团队的短期业务需求，业务方不满，觉得花了钱没有得到相应的服务；中台团队责因为背负着业务的持续施压，无法按照自己的节奏推进中台建设，痛苦不堪，矛盾产生。我管这种矛盾叫做：短期战术目标与长期战略目标的矛盾。
一种情况是，中台团队迫于压力极力满足前台的需求。但因为中台的企业级性质，中台团队需要同时面对多个不同的前台业务、前台团队。因为每一个前台团队都是“金主、客户、甲方”，在中台团队眼中地位是一样的，都是需要极力满足需求的。而因为前台团队“花了钱”，为了能获取更多的中台资源使用权，自然都会给中台团队提出各种各样的需求，来争取到更多的中台资源，导致中台团队的需求短时间剧增，但因为毕竟中台的资源有限，所以自然而然会出现之前反复提到的需求剧增、排期、冲突等问题，矛盾产生。我管这种矛盾叫做：多前台由于中台资源竞争所产生的矛盾。

(2)产品化中台建设

如果中台是一个产品，则意味着：

中台作为产品需要有自己的愿景定位，不一定需要满足所有前台客户的需求，这同样也意味着前台可以选择不使用中台的某些能力而选择自建。
中台作为产品需要有自己清晰的用户定位和用户划分，前台作为中台的用户不再是平等的，VIP前台用户的需求要优于免费前台用户的诉求，通过产品上常见的用户划分来解决需求膨胀、排期、优先级和冲突问题。
中台作为一个产品，需要想方设法体现自身的价值，真正为前台客户解决实际问题，并关注前台用户体验，通过营销和售前等手段获取前台客户，通过清晰的用户定位和产品力吸引前台客户，让其主动选择采购中台产品。
产品的建设初期，不一定启动资金直接从业务上切分，可能需要类似于天使投资的企业战略投资进行初始孵化，减少中台前期建设的业务交付压力，甚至作为企业的战略级产品，需要一些内部保护和孵化，但仍需要快速验证其价值，获取客户，实现自负盈亏。
产品的建设过程可以借鉴精益创业思路，需要尽快体现其商业价值，如果一定时期内无法获取相应的前台用户（前台不用），或是其他考核指标不达标，则需要进行中台建设止损，类似于创业失败。
甚至在特殊情况下，允许同一类型的中台产品存在合理的内部竞争，同时对两个相似的中台产品进行孵化，使用类似于内部赛马的机制解决内部服务差异性带来的内部产品垄断和定价困难问题。
中台产品为了用户留存，需要对于前台客户提供产品级SLA，提供客户运营，客户售后服务，保持产品平滑更新，关注用户满意度，实现客户留存与转化。

2.中台建设前必须想清楚的问题

(1)中台建设的愿景是什么？

中台就像一个产品一样，需要一个明确的愿景，要让所有人能够清晰明确地知道，中台建设对于企业对于业务的价值，从而可以一起始终向着同一个方向持续前进。如果愿景缺失，那就会很容易在中台建设过程中迷失自己的方向，失去定力。(明确建中台是为了解决的问题，对于企业和业务的价值)。

愿景帮助了解自己中台建设的目标，帮助判断哪些事情是符合中台建设愿景的，作为中台团队我们需要去考虑。在这之外，更重要的是帮我们判断哪些事情不是中台要去做的，为中台做减法，这点在中台的建设过程中其实更加重要。

所以在建设中台前，第一个要问自己的就是：建设中台，愿景是什么？而且更重要的是这个愿景是需要所有的角色，上到企业管理层，下到每一位中台的相关人员都要明确并达成一致的。

(2)中台的用户和客户是谁？

中台的建设通常都会伴随企业内的组织重构以及利益和职责的再分配。如果没有搞清楚中台建设的各个干系方关系，必然在中台的建设过程中就会四面碰壁，陷入“干系人旋涡”之中，面临多方面的阻力，陷入一个非常被动的局面。

所以在中台建设之前，最好先搞清楚中台如果作为一款产品，它的用户是谁？客户又是谁？用户和客户是一个群体么？除了用户和客户还有哪些干系方？他们对于中台都有什么期望，这些期望又是否一致呢？

中台因为其所处的特殊位置，干系方往往纷繁复杂。在保持自己方向的前提下，找到各方利益的结合点(比如某一条业务线更关注短期的战术目标)，是一件非常困难且有必要的事情。否则，在建设过程中就会受到各方的阻力，产生摩擦，导致中台很难推进落地。需要找到企业管理层与业务线关注点的结合点，也就是长期战略价值和短期战术价值的结合点。推动者职级一定要高

但反过来讲，中台也不应该只是极力去满足各方的诉求，中台团队毕竟不是业务的外包团队。中台需要有自己的思想和规划，要能做到听得进别人的话，但是还要明确自己的目标，走自己的路。而自己的目标，就是来源于上面提到的中台建设愿景，而中台的愿景也往往来源于企业的战略需要。

中台建设虽然需要兼顾各方的利益，但更多主要还是解决企业管理层对于公司长期生存与可持续发展的恐惧与焦虑问题。

(3)中台的钱由谁出？

对于企业内部，可能代表的就是人和资源。所以，这个问题还可以引申到中台的人从哪来？从前台团队借调么？还是重新招聘新组建呢？一个中台建设往往会持续很长的时间，那这些人的成本又由谁来承担呢？如果说中台是为前台业务赋能的，是不是就应该从前台各业务的预算中划分出一部分作为中台的建设预算呢？

市面上的中台建设，如果从投资结构来讲，基本上可以分为两种类型，即“众筹模式”和“投融资模式”。当然，我们还能看到这两种类型的混合模式。

众筹模式：从业务前台集资，有钱的捧个钱场没钱的碰个人场，能出预算的出预算，能出人的出人，来组建中台团队，然后再反过来服务于前台业务团队
投融资模式(推荐)：中台建设的前期（从 0 到 1），由企业本身的战略储备资源投资建设。经过一定时间的建设期，比如 6个月，然后逐渐找适合的前台业务进行试点接入，如果效果好的话再推广到更多的前台业务团队。当服务稳定之后，对前台也产生了稳定的价值之后，再逐渐从前台收取一定的资源，可以是人也可以是其他资源，既所谓的收回投资并实现盈利。这里的盈利只是个比喻，可能是满足了企业管理层对于企业战略目标的需求。

内部抽调是重要来源；人员大都既懂业务，又得懂技术；团队内部最好有一个沟通和协调能力较强的人员，这个人是中台团队对外沟通的桥梁，不同企业叫法不同，比如阿里最为核心的角色是业务架构师，但可以简单理解为中台的产品经理。

(4)中台的目标如何验证

目前业界有一些中台的考核标准我们可以作为参考，例如阿里巴巴的中台考核就是设计成：40% 稳定性 +25% 业务创新 +20% 服务接入量 +15% 客户满意度。

具体到一家企业某个中台的验证指标设计，这是一个复杂过程，而且往往还会不断演进，需要结合上面提到的中台愿景、投资模式、干系人利益点以及其他相关因素来综合设计。

3.D4 模型

第一个阶段是Discovery，帮助我们在中台规划前先建立全局视野。在这个过程中我们以企业愿景和战略为输入，结合行业趋势、竞争对手分析、用户客群分析、业务现状分析、IT资产盘点，全方位多角度地理解企业的战略市场环境以及业务及 IT 全貌，帮助我们做出最正确的判断。
第二个阶段是Define，帮助我们基于之前 Discovery 发散的各维度信息进行收敛与分析，对于中台的架构进行定义。通过对跨业务线的业务梳理进行重合度分析，并结合领域分析对业务表象之后的企业核心问题域做进一步展开和重合度分析，一起来收敛推导基于中台的企业架构设计。并基于多维度的打分，形成具体的实施路径规划，说白了就是先做什么后做什么。这里需要注意一点，此时收敛的是仍是企业架构层面，像业务中台、数据中台这种级别的产品，可能只是实施路径中的一个项目，在这个阶段也可以回答那个我们关心的问题，我们到底需不需要中台，需要哪些中台？
第三个阶段是Design，帮助我们针对实施路径中的某一个产品，例如业务中台，做详细的设计，包括产品级的业务需求分析、功能及架构设计、实施计划等。例如对于业务中台产品，在 Design 阶段我们需要回答产品的愿景、边界、产品形态、技术架构、交付计划、成本预估等等，这个过程就是一个标准的产品设计过程，只不过在中台项目中大多是针对中台类的产品而已。
第四个阶段就是Delivery，这个时候我们就可以针对一个设计好的中台，开始具体的交付过程，我们采用的是敏捷结合精益软件开发的方式，用快速迭代和基于反馈的调整，最大程度地弥补由中台建设本身的复杂度带来的设计偏差和其他的交付问题，并且注重架构的治理与守护，减少实现与设计的偏离。

四、业务中台落地

1. PD

D4 的前两部分 Discovery 和 Define 合起来，就是一个在企业级先发散再收敛的过程。对这个过程有一个称呼，叫作Portfolio Discovery，简称为 PD。实际实施时，PD 是一个 4～8 周的头脑风暴工作坊。

对于中台的整体规划，也就是回答要不要建中台、建哪些中台、谁先建谁后建这些问题。

我需要花多少钱在数字化建设上？
这些钱该怎么花？怎么分配？要新增哪些系统，是购买还是自研？要干掉哪些系统？优化
哪些系统？继续维护哪些系统？保持哪些系统不变？
要不要建个中台

中台这种解决方案到底适合不适合企业，仍然是需要调研和判断的。所以，如果我们一开始就把中台作为一个确定的既定方向，难免会限制住我们的视野，有可能会错过比中台更好、更简单、更有效的解决方案，或是过早地进行过度设计，在根本不需要中台的场景下，大张旗鼓地开展中台建设，劳民伤财。

那企业到底要不要划分出一部分钱和资源来做中台建设？对公司来讲添加中台这样一个新的架构层次有什么价值？什么时候做最好？优先级怎么样？这也正是 PD 所主要关注和需要回答的问题。

而为了避免拍脑袋的情况出现，Discovery 作为 PD 的前半程，主要目的就是做充分的发散和调研，也就是利用各种工具和手段帮助我们充分了解行业趋势、竞争对手的情况、公司的战略分解以及自下而上的现状调研等信息和环境，为下一个阶段 Define 的收敛，也就是对于企业新的业务架构、应用架构、技术架构甚至是组织架构的设计，提供充分的信息支撑和依据。

2.企业战略分解及现状调研

(1)由外到内：行业与竞争对手分析

所谓知己知彼百战不殆，在详细了解自身之前，我们有必要先将视野放开一些，看看行业的大趋势与竞争对手都在做些什么。

“点 - 线 - 面 - 体”的理论。

点：中台本身只是一个点，那它可能只是一家企业发展到一定阶段的产物，不是开始也肯定不是结束。
线：从一家企业的发展过程这条主线上来看待中台这件事情，来看这个点。它从哪里来？为什么会出现？又将向哪儿去？甚至思考中台的下一个阶段会是什么？会被什么替代？
面：同一个行业中的其他线，也就是同一行业中的其他企业在做什么？战略都是什么？数字化建设的重点又是什么？有没有同时在做中台建设？建设的目标又是什么？效果怎么样？但这里要注意的是，分析不一定就代表要直接借鉴，人家都在建中台我们就要建中台。
体：从其他的行业，其他的面上来学习。如果其他面上有好的概念或是方法，我们可以借鉴过来，帮助自己的企业在自己的行业里取得先机。中台这个概念起始于互联网行业，目前就正在被各个行业参考和借鉴。

业界已经有了很多非常成熟的方法，可以直接使用，例如常见的：五力模型，SWOT，商业模式画布，竞争对手产品线分析，竞争态势分析矩阵等。

(2)自上而下：企业战略分解

愿景是到达一定时间希望企业可以变成的样子或是达到的目标

依据战略平衡三角形，在企业的愿景和目标已经确定的情况下：

企业战略就可以简化理解成：结合企业自身的能力与其所处的环境，到底需要采取什么样的举措，才能实现企业预定的愿景和目标呢？
而企业战略分解就可以简化理解成：结合企业各部门自身的能力与其所处的环境，到底需要采取什么样的举措，才能实现企业预定的愿景和目标呢？

对于企业战略的分解，业界也有很多工具和实践，例如 BMGovernance设计的企业战略分析模型等。但为了应对变化越来越快的市场环境，在 PD 中我们使用的是精益价值树（Lean Value Tree）的工具来帮助做战略愿景的分解的。

精益价值树是一种以价值成效为导向，用于分析和沟通业务愿景、战略与投资的工具。它的核心是建立从愿景、目标到投资举措自上而下的对齐，因此采用一种逐层分解的树形结构，如下示意图：

(3)自下而上：现状调研与分析

如果把企业战略分解理解成从企业愿景自上而下的分析推导过程，那是不是直接按照推导出的举措具体实施就可以了呢？往往还是不够的，因为每家企业经过长时间在市场中的搏杀，能生存并发展到现在，都会出现各种各样的问题和限制。如果脱离现状，无视这些问题与限制，就肯定会面临非常大的阻力与风险。

所以不但要自上而下地做企业战略的分解，以此来帮助我们思考中台或是其他举措是否必要。同样需要充分地做自下而上的现状调研，来帮助我们了解现状和历史。一方面充分尊重过去遇到的所有问题，收集汇总痛点；另一方面又要求我们能跳出过去的限制，重新从业务出发，从用户出发，去重新探索基于新技术、新架构下的一些新的可能性。

这里常用的工具和实践也很多，例如高层访谈、干系人地图、组织架构分析、战略设计思维、业务架构现状梳理、用户旅程、服务蓝图、领域驱动设计、应用系统现状梳理、技术架构现状梳理等等。

充分且多维度的现状调研与分析，不但能让我们对于业务、应用、技术、数据、组织现状，也就是企业架构现状有一个全面清晰的认识，还可以通过访谈与调研，补充时间线上的上下文，包括过去发生了什么？为什么现状是这样子的？未来大家希望是什么样的？为什么？

不过这里有一个问题需要关注，那就是梳理的范围和深度。不要忘了我们此时做的是企业级的架构梳理，宽度和范围可能会远远超过我们的想象。如果深度控制不好，会发现转了半天还是在一个小的领域和业务线原地打转。所以面对这种问题和风险，建议:

先完成自上而下的企业战略分解，再开展自下而上的现状调研。因为做完战略分解，我们已经对于公司的行业、业务、愿景、战略已经有了一些了解，再开展调研的时候就会有个全局的把控，对于粒度和深度都更容易拿捏。
做好充分的准备，能够提前通过阅读资料和小范围调研完成的内容就提前完成。
制定详细的计划，可以按照现状调研的总时间倒推梳理的范围和粒度。如果时间足够，可以用两天的时间梳理一条业务线的业务架构，这样梳理就可以深入一些。但如果只有半天，则粒度可以适当放粗，先保证有一个全局业务视图。
建议刚开始做的时候，可以粒度粗一些，不要过早陷入细节，不过粒度到底如何控制确实需要对于公司战略以及业务有深入理解，也是最见功夫的地方。在判断不好的时候，可以先粗一些，如果最后还有时间，也可以再做一轮调研向下再展开一层。

这样的现状调研工作，对于一个中型的有四五条不同业务线的企业，我们实际实施大概需要2～4 周左右的时间，当然还要视客户而定。完成调研工作后，我们就对企业各方面的现状有了一个比较全面的了解，并且也收集到了每条业务线大量的痛点和问题，这样就有了对未来架构的展望。

3.企业数字化全景规划

(1)中台复用的能力类型

业务数据、业务功能、业务流程以及通用的技术能力

(2)使用DDD识别复用能力

中台本质上是领域的子域，它可能是核心域，也可能是通用域或支撑域。通常大家认为阿里的中台对应 DDD 的通用域，将通用的公共能力沉淀为中台，对外提供通用共享服务。

使用领域驱动设计结合事件风暴这两个工具，通过工作坊的形式来对业务流程背后的问题空间和解空间做进一步的分析，识别出关键聚合，再通过跨业务线的问题域叠加投影，找出大家共同关注的问题空间和聚合，从而继续扩展来做共性场景和能力识别。

①中台建设要聚焦领域模型

中台需要站在全企业的高度考虑能力的共享和复用。中台设计时，需要建立中台内所有限界上下文的领域模型，DDD 建模过程中会考虑架构演进和功能的重新组合。领域模型建立的过程会对业务和应用进行清晰的逻辑和物理边界（微服务）划分。领域模型的结果会影响到后续的系统模型、架构模型和代码模型，最终影响到微服务的拆分和项目落地。因此，在中台设计中首先要聚焦领域模型，将它放在核心位置。

②项目级微服务与中台微服务

项目级微服务：可以组合和编排外部微服务的应用服务。它只要将编排后的服务发布到 API 网关供前端调用，这样前端就可以直接访问自己的微服务了。

企业级中台微服务：企业级的业务流程往往是多个中台微服务一起协作完成的，企业级中台微服务的集成不能像项目级微服务一样，在某一个微服务内完成跨微服务的服务组合和编排。可以在中台微服务之上增加一层，它的主要职能就是处理跨中台微服务的服务组合和编排，以及微服务之间的协调，它还可以完成前端不同渠道应用的适配。

4.中台的规划与设计

(1)确定中台产品愿景

中台的愿景作为所有问题的出发点，需要足够简单明确，才能做到像一个指南针一样，成为我们中台建设过程中指引方向的工具，也才能做到“遇事不决看愿景”。

(2)确定业务梳理范围

是不是所有的业务线都要梳理？是不是端到端的所有阶段都要梳理？业务梳理要到什么样的粒度？这些都是经常面对的问题。

从业务线上来看，就不一定所有的业务线都需要梳理。将关联紧密的业务梳理到一起，长期独立发展的与其它业务线关联不大的不应梳理到一起。

(3)细粒度业务梳理

一般大家的做法都是基于现有的流程或系统，对现有业务的流程进行梳理，例如在电子商务领域大家经常提到的四流，具体指的是信息流、商流、资金流、物流的梳理工作，使用的工具也大多是流程图这种非常成熟的工具。

但是这种基于已有流程的梳理有时候会有一些限制，简单讲就是可能会基于过去遗留的业务债推导出伪中台需求。什么意思呢？就是对于一些长期且成熟的业务，现有的业务方式可能并不是一个最好的方式，而是由于长时间发展以及和过去的各种周边限制以及 IT 限制妥协的产物。

这种回到问题域本身，回到问题的原点，基于用户需求在当前的业务及技术条件下，重新设计解决方案的思维方法，可以避开上面提到的业务债陷阱，也多用于创新型业务的设计过程，而这种思维方式也大量参考和借鉴了设计思维的方法。

所以和基于现状的传统业务流程梳理不同，我们在业务梳理过程中大量地采用了基于设计思维，结合用户体验地图（User Journey Map）和服务蓝图（Service Map）的方式。回到业务本身，从问题域出发，以用户为中心，进行用户体验设计和业务服务蓝图的梳理。

通过范围内的业务架构梳理，再结合最后的跨场景通用能力的分析，我们就可以对关注领域的业务全貌有了一定深入的了解，并且可以识别出不同业务线中一些可复用的业务数据、业务功能与业务流程。而这些通用的业务数据、业务功能、业务流程经过加工分析就形成了中台的具体需求。对于这些需求，我们是通过用户故事（User Story）的方式描述的。

(4)确定 MVP

(1)运营前置：制定迭代计划及接入计划

对于中台可能就是中台产品推广、前台（用户）接入计划以及接入后的运营支持。如果中台建设的中后期才开始考虑这些问题，往往就有些晚了。

而且很多情况下，前台是不会停下来等中台建设完，等接入后再开始自己的业务演进，所以往往都是前中台并行。所以提前考量运营计划尤其是接入计划，尽量使用合理的接入计划来规避一些风险，对于中台产品的建设也非常关键。

(2)度量前置：定义验证指标

市面上最常见到的产品度量指标，分为了四个大类，也就是战略类、用户类、市场拓展类与降本提效类。基于每一个维度展开，都能找到很多的常用度量指标。

而对于中台来讲，与市场和用户之间还隔着一层前台，所以在度量上就不如直接接触用户的前台系统这么清晰。但是中台是为前台业务赋能的，又不能脱离开业务，单纯只在技术上做一些度量，例如接口稳定性和接口数量等，这样也不符合中台对于业务支撑赋能的定位和价值。

所以一般在考虑中台的度量指标的时候，还是把战略价值和业务价值作为出发点，开始拆解和推导，并且按照干系人关注点的不同，用多维度、多层次的指标设计来审视中台建设的效果。这里要强调一下，虽然维度和视角不同，我们要保证所有指标体现的中台建设目标必须是一个。

而具体到实施方法，因为每一个中台产品都是不一样的，所以很难给一个标准的答案。在实操过程中，建议你多换位思考，多问几个“怎么（How）”。相信你比较熟悉 5Why 分析法，这里可以稍微改一下，用5How来驱动验证指标的设计。

那我怎么判断中台建设的成果？如果回答是看对于新业务的赋能，
那我怎么验证对于新业务的赋能效果？如果回答是看新业务的上线速度，
那我怎么验证新业务的上线速度？如果回答是看新业务从立项到上线的时间，
那我怎么验证……

5.中台的建设与接入

中台所处的特殊位置，对产品界定要求和对建模的难度，都比其他终端产品的复杂度要高一个级别，所以我们建议采用精益的产品研发流程，保持小步迭代、快速建设、快速度量、快速反馈、快速调整的流程，保证中台建设是一个持续演进和被业务驱动的过程。

(1)精益产品研发流程

这里叫精益产品研发流程，主要是面对中台建设过程中的不确定性，引入精益思想来实现价值的定义和快速流动及度量，再结合敏捷开发实践，让整个软件开发过程轻量、迅速、敏捷、价值驱动。

精益思想之所以流行，关键在于其定义了一套完整的思想框架，而最终核心目标就是消除浪费、创造价值。在中台的实际建设过程中，我们也建议引入精益思想，结合到软件的开发过程中，小批量快速开发产品，快速引入度量，基于测量的数据快速对于之前的需求假设进行验证和认知，并基于此做快速的调整。

敏捷关注的是价值确定的情况下，如何通过小步快跑的迭代方式按节奏交付价值；而精益关注的则是在价值并不确定的情况下，如何用最小成本，快速定位到真正价值点。

由于中台建设的复杂度非常高，所以将精益思想结合敏捷思想应用到中台的建设和开发过程，再配合后边马上会谈到的中台运营机制的建立，可以让我们更好地应对中台建设过程中的各种问题，例如最经典的中台边界界定问题。

(2)中台的运营、治理与演进

除了中台的建设过程，同样不能忽视的就是对于中台建设过程中的持续治理及演进，以及真正接入了前台之后对于中台的运营管理。如果没有运营管理则会在建设过程中产生很多困难和问题

①中台产品的用户划分

中台作为一个公共服务部门，一定会碰到多个前台的需求、排期、质量要求、非功能需求出现不同的情况，甚至也会经常出现多个前台之间的需求或是非功能性需求彼此矛盾的时候。而中台的资源有限，且有自己的愿景，不可能无条件地满足所有前台用户的诉求，往往就会陷入疲于应对的状态，对前台的响应和服务质量也会急速降低。

怎么办呢？问题的根本在于，虽然我们说中台是企业级能力复用平台，但我们经常会忽略的一点就是，如果我们采用产品化的思维来构建中台，那中台中所沉淀的能力并不是产品的全部，还需要再加上 NFR（非功能性需求）或是我们常说 SLA（Service-Level

Agreement，服务等级协议）才是产品，因为不同的前台用户之间，不只是对于中台产品的功能本身有着不同的诉求，同样对于 NFR 或是 SLA 也有着不同的诉求。简单举个例子，比如核心业务对于中台的 SLA 稳定性的要求可能是 5 个 9，性能是 5 毫秒；而一个新的创新型应用，可能还没有用户，就不需要有这么高的要求。

②Offering = Capability + SLA/NFR

对于前台用户基于需要的能力和 NFR/SLA 做用户划分。

最常见的就是三层用户划分机制。通过对于前台用户的分层，我们就可以为不同层次的用户指定不同的需求响应机制、不同的沟通管理机制、不同的服务质量控制机制、不同的问题处理及升级机制等等。自然不同的服务类型作为前台用户也需要付出不同的成本或是资源（人或钱），甚至前台与中台可以通过签署 SLA 来实现对于前台用户的服务承诺

举个例子，当我们开始中台建设时，可以只找到一个或是两个种子用户，作为 Tier1 级别的用户来服务。对于这个种子用户的需求作为最高优先级的需求来对待，并建立例行的沟通机制和服务响应机制。因为此时的服务还处于初建时期，还不是特别的成熟，所以可以采用“免费”的方式动用企业的战略资源来进行建设。这样，对于前台用户来讲，资源是免费的，而且是一对一式服务，自然也会乐意配合到中台的建设过程中。

当中台建设到一定阶段之后，对于种子用户的服务已经接近稳定，有了一定的能力沉淀，也能释放出一定的资源了，就可以利用释放出来的资源开始为 Tier3 层的用户构建自助服务控制台（Self-Service Console），并着手构建中台产品的运营团队，制定 Tier3 层的NFR/SLA。在很多互联网企业，这个过程常常由于做出来的自助服务控制台比较粗糙，看起来也像是对于平台服务的增强和可用性优化和治理的过程，大多数就是一个白屏幕，加一些的配置选项，所以常被称为“平台的白屏化”。

当中台的自助服务控制台创建完成，Tier3 层次的 SLA 也构建完成后，我们就可以重新签订 SLA，将之前的 Tier1 用户迁移到 Tier3 层次，即完成之前种子用户从定制化服务到自助式服务的迁移过程，从而释放出更多的资源用于接入新的前台用户。

如果由于种种原因，无法一步到位实现服务的完全自助化，还可以通过构建 Tier2 层的SLA，也可以通过重新签订 SLA，将之前的 Tier1 用户迁移到 Tier2 层次，通过“自助+VIP 服务”的方式，保持对前期种子用户服务连贯性的同时释放出尽可能多的资源。

此时我们就已经有了三层的用户划分机制，可以在企业内更大范围地发布 Tier3 的自助式服务，通过这种方式实现更多用户的接入。同时，因为已经释放出一些中台的资源，就可以继续选取下一个关键的种子用户（一般是关键业务），作为新的 Tier1 级用户开始第二轮中台建设的推进。

6.落地中台

渠道 & 应用渠道 & 应用层，这是整个系统的对外部分，包括了各个应用的前端，如 App、小程序、公众号等等，这些是需要定制的部分。同时，在对外部分，我们还会提供 Open API，供上下游企业调用。
应用平台应用平台是各个具体应用的母体，它包含了各个应用的服务端，比如小程序服务端、App 服务端等等，这些服务端会针对具体场景，做流程编排和信息的聚合。服务端和前端之间还有一个网关，网关实现前后端隔离，具体负责外部访问的安全验证和监控，以及内外部请求的路由和消息格式转换。
业务中台业务中台是中台架构的核心，它包括一系列的通用基础服务，以及它上面的通用聚合服务和下面的技术平台，这个在前面已经详细介绍过了，我就不赘述了。
后台后台包括两部分，第一部分是适配插件，用于连接商户内部系统和中台基础服务，比如，在中台的商品服务和后台 ERP 之间同步商品数据，在中台的会员服务和后台 CRM 之间同步会员信息。一般针对每个内部系统，都有一个适配插件，它起到了类似硬件驱动程序的作用，这个一般是定制化的。第二部分是企业内部系统，这个是企业的 IT 基础设施，业务最终会在这里落地。

五、使用DDD规划和设计中台

1.DDD、中台和微服务的协作

DDD 有两把利器，那就是它的战略设计和战术设计方法。

中台更多偏向业务模型，形成过程是业务领域不断细分的过程，过程中会将同类通用的业务能力进行聚合和业务重构，再根据限界上下文和业务内聚的原则建立领域模型。而 DDD 的战略设计最擅长的就是领域建模。

在中台完成领域建模后，就需要通过微服务来完成系统建设。此时，DDD 的战术设计又恰好可以与微服务的设计完美结合。可以说，中台和微服务正是 DDD 实战的最佳场景。

中台是微服务的升级。在微服务架构下搭建的是一个个离散的服务，如商品服务、订单服务等等。而在中台里，这些微服务升级为了商品中心、订单中心，每个中心更强调体系化，包括更好的业务通用能力，更好的系统运营能力（如监控、稳定性、性能的强化），更好的业务运营能力（比如商品中心自带配套的商品管理后台）。每个服务中心都围绕核心业务，自成体系，成为一个微内核，这些微内核形成一个有机整体，共同构成了基础业务平台，也就是中台。松散的微服务 -> 共享服务体系 -> 中台，这是微服务架构向中台架构的演进过程。

(1)DDD、中台和微服务的协作模式

更多的企业还是会聚焦在传统企业中台建设的模式，也就是将通用能力与核心能力全部中台化，以满足不同渠道核心业务能力的复用。

可以将需要共享的公共能力进行领域建模，建设可共享的通用中台。除此之外，还会将核心能力进行领域建模，建设面向不同渠道的可复用的核心中台。而这里的通用中台和核心中台都属于业务中台的范畴。

DDD 的子域分为核心域、通用域和支撑域。划分这几个子域的主要目的是为了确定战略资源的投入，一般来说战略投入的重点是核心域，因此后面就可以暂时不严格区分支撑域和通用域了。领域、中台以及微服务虽然属于不同层面的东西，但还是可以将他们分解对照，整理出来它们之间的关系。下面这张图，从 DDD 领域建模和中台建设这两个不同的视角对同一个企业的业务架构进行分析。

如果将企业内整个业务域作为一个问题域的话，企业内的所有业务就是一个领域。在进行领域细分时，从 DDD 视角来看，子域可分为核心域、通用域和支撑域。从中台建设的视角来看，业务域细分后的业务中台，可分为核心中台和通用中台。从领域功能属性和重要性对照来看，通用中台对应 DDD 的通用域和支撑域，核心中台对应 DDD 的核心域。从领域的功能范围来看，子域与中台是一致的。领域模型所在的限界上下文对应微服务。建立了这个映射关系，我们就可以用 DDD 来进行中台业务建模了。

这里还是以保险领域为例。保险域的业务中台分为两类：第一类是提供保险核心业务能力的核心中台（比如营销、承保和理赔等业务）；第二类是支撑核心业务流程完成保险全流程的通用中台（比如订单、支付、客户和用户等）。根据 DDD 首先要建立通用语言的原则，在将 DDD 的方法引入中台设计时，我们要先建立中台和 DDD 的通用语言。这里的子域与中台是一致的，那我们就可以将子域统一为中台。

中台通过事件风暴可以进一步细分，最终完成业务领域建模。中台业务领域的功能不同，限界上下文的数量和大小就会不一样，领域模型也会不一样。

当完成业务建模后，就可以采用 DDD 战术设计，设计出聚合、实体、领域事件、领域服务以及应用服务等领域对象，再利用分层架构模型完成微服务的设计。这就是 DDD、中台和微服务在应用过程中的协作模式。

(2)中台如何建模？

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

第一步：按照业务流程（通常适用于核心域）或者功能属性、集合（通常适用于通用域或支撑域），将业务域细分为多个中台，再根据功能属性或重要性归类到核心中台或通用中台。核心中台设计时要考虑核心竞争力，通用中台要站在企业高度考虑共享和复用能力。

第二步：选取中台，根据用例、业务场景或用户旅程完成事件风暴，找出实体、聚合和限界上下文。依次进行领域分解，建立领域模型。由于不同中台独立建模，某些领域对象或功能可能会重复出现在其它领域模型中，也有可能本该是同一个聚合的领域对象或功能，却分散在其它的中台里，这样会导致领域模型不完整或者业务不内聚。这里先不要着急，这一步我们只需要初步确定主领域模型就可以了，在第三步中我们还会提炼并重组这些领域对象。

第三步：以主领域模型为基础，扫描其它中台领域模型，检查并确定是否存在重复或者需要重组的领域对象、功能，提炼并重构主领域模型，完成最终的领域模型设计。

第四步：选择其它主领域模型重复第三步，直到所有主领域模型完成比对和重构。

第五步：基于领域模型完成微服务设计，完成系统落地。

如果还是以保险领域为例的话，完成领域建模后，里面的数据就可以填上了。以通用中台的用户、客户和订单三个中台来做示例。客户中台提炼出了两个领域模型：客户信息和客户视图模型。用户中台提炼出了三个领域模型：用户管理、登录认证和权限模型。订单中台提炼出了订单模型。

2.用DDD重构中台业务模型

以保险行业的互联网电商和传统核心应用来做个对比分析。下面这张图，这两者在业务功能上会有很多相似和差异，这种相似和差异主要体现在四个方面。

核心能力的重复建设。由于销售同质保险产品，二者在核心业务流程和功能上必然相似，因此在核心业务能力上存在功能重叠是不可避免的。传统保险核心应用有报价、投保、核保和出单功能，同样在互联网电商平台也有。这就是核心能力的重复建设。
通用能力的重复建设。传统核心应用的通用平台大而全，通常会比较重。而互联网电商平台离不开这些通用能力的支撑，但为了保持敏捷性，一般会自己建设缩小版的通用功能，比如用户、客户等。这是通用能力的重复建设。
业务职能的分离建设。有一类业务功能，在互联网电商平台中建设了一部分，在传统核心应用中也建设了一部分，二者功能不重叠而且还互补，组合在一起是一个完整的业务职能。比如缴费功能，互联网电商平台主要面向个人客户，于是采用了支付宝和微信支付的方式。而传统核心应用主要是柜台操作，仍在采用移动 POS 机的缴费方式。二者都是缴费，为了保证业务模型的完整性，在构建中台业务模型时，我们可以考虑将这两部分模型重组为一个完整的业务模型。
互联网电商平台和传统核心功能前后完全独立建设。传统核心应用主要面向柜台，不需要互联网电商平台的在线客户、话务、订单和购物车等功能。而互联网电商平台主要面向个人客户，它不需要后端比较重的再保、佣金、打印等功能。在构建中台业务模型时，对这种情况应区别对待，将面向后端业务管理的应用沉淀到后台，将前端能力构建为面向互联网渠道的通用中台，比如订单等。

可以用 DDD 领域建模的方法来构建中台业务模型。有两种建模策略：自顶向下和自底向上的策略。

(1)自顶向下的策略

这种策略是先做顶层设计，从最高领域逐级分解为中台，分别建立领域模型，根据业务属性分为通用中台或核心中台。领域建模过程主要基于业务现状，暂时不考虑系统现状。自顶向下的策略适用于全新的应用系统建设，或旧系统推倒重建的情况。

由于这种策略不必受限于现有系统，可以用 DDD 领域逐级分解的领域建模方法。从下面这张图可以看出它的主要步骤：第一步是将领域分解为子域，子域可以分为核心域、通用域和支撑域；第二步是对子域建模，划分领域边界，建立领域模型和限界上下文；第三步则是根据限界上下文进行微服务设计。

(2)自底向上的策略

这种策略是基于业务和系统现状完成领域建模。首先分别完成系统所在业务域的领域建模；然后对齐业务域，找出具有同类或相似业务功能的领域模型，对比分析领域模型的差异，重组领域对象，重构领域模型。这个过程会沉淀公共和复用的业务能力，会将分散的业务模型整合。自底向上策略适用于遗留系统业务模型的演进式重构。

以互联网电商和传统核心应用的几个典型业务域为例，采用自底向上的策略来构建中台业务模型，主要分为这样三个步骤。

第一步：锁定系统所在业务域，构建领域模型。

锁定系统所在的业务域，采用事件风暴，找出领域对象，构建聚合，划分限界上下文，建立领域模型。下面这张图，选取了传统核心应用的用户、客户、传统收付和承保四个业务域以及互联网电商业务域，共计五个业务域来完成领域建模。

可以看到传统核心共构建了八个领域模型。其中用户域构建了用户认证和权限两个领域模型，客户域构建了个人和团体两个领域模型，传统收付构建了 POS 刷卡领域模型，承保域构建了定报价、投保和保单管理三个领域模型。

互联网电商构建了报价、投保、订单、客户、用户认证和移动收付六个领域模型。

在这些领域模型的清单里，可以看到二者之间有很多名称相似的领域模型。深入分析后会发现，这些名称相似的领域模型存在业务能力重复，或者业务职能分散（比如移动支付和传统支付）的问题。那在构建中台业务模型时，就需要重点关注它们，将这些不同领域模型中重复的业务能力沉淀到中台业务模型中，将分散的领域模型整合到统一的中台业务模型中，对外提供统一的共享的中台服务。

第二步：对齐业务域，构建中台业务模型。

下面这张图，可以看到右侧的传统核心领域模型明显多于左侧的互联网电商，可以得出一个初步的结论：传统核心面向企业内大部分应用，大而全，领域模型相对完备，而互联网电商面向单一渠道，领域模型相对单一。