龄化转型案例阿里中台设计流程及方法在过去几年中台项目的实践中，我们团队积累了一套成熟的中台服务中心建设思路，该思路 包含了从业务调研到中台设计开发的标准流程和方法论，值得企业在进行中台建设时参考我们把业务中台的落地方法总结为一个流程图，如图4-1所示从业务的调研与规划开始，到产出中台设计，大致步骤包括：1） 调研与规划2） 需求分析3） 中台设计4） 开发实现业务域图4-1业务中台设计流程1,调研与A业务模型I数榭模W*服务能力申合规范*业务中心解A推演选代分析3.中台 设计/业务中心（1）调研与顾业务的调研与规划目标是，从发展角度去看企业当下的业务运营情况和未来的业务规划这 一步非常重要，业务规划的长远度决定了业务中台的高度所以这里要求业务方综合考虑企 业自身的特性、新技术应用、新业务发展趋势等方面这里列举一个零售行业某企业的例 子，如图4-2所示r全R库，时视'・鲨,供V丹中心.室理不同枝统上血1换宰摧为的沉握・仃站靠N款郝J霆 推，KjSfl^tiS^ 灯卜理喝•绶 Fwse± -a颂式/吊秘益忌牌的仙度ni忌 财»会蜡故抠分析.就准件牌・睥.W.域世.岫暗,电商3瞰♦他式补ttm高ay?. &摊存-翔鄙物映尘 弟道中虬安崖 020•枷统Et*跨明弗汕iL啊J：, 靴i建注告靠申 台姓昂勉缶•隽H传J,施！1•高蚊世配荷货体卷统服务 统会员 统-营销 统商品 统-库存 统寸作图4-2零梆行业某企业的中台规切示例 ■<.技才琐话从这个业务规划中，能明确看到企业中台建设的总体规划，在不同阶段对于会员、库存、营 销以及供应链方面的业务诉求。
有了规划，接下来的中台分析设计就更加有的放矢，不会出 现目标混淆和不可持续发展的问题2)需求分析业务规划之后就是需求分析，单纯从中台设计的角度来说，需求分析更关注粗粒度核心业务 流程，并不关心业务层面具体的用户交互和功能细节需求一般业务系统和中台架构设计的 需求调研都是同步进行的，所以这里也不用分得太清晰需求分析的目标是，从业务规划的各种业务场景出发，梳理核心业务流程业务流程的粒度 需要包含这几类：业务角色、业务实体、业务规则、已经存在的业务系统的接口、夕卜部系统 或者平台的服务和接口这个过程是边梳理业务流程边识别业务实体，两者相辅相成⑶中台设计从需求分析到中台设计有两条路径，如前面图4-1所示路径A是从业务域分析开始的完 整过程，经过流程分析、时序图分析和聚合分析，最后得出中台设计方案；路径B针对业 务比较明确和相对简单的场景，或者行业已经有类似的业务沉淀(行业模型库)，可以基于 这些模型库进行迭代，直接基于已有的方案开始迭代推演下面我们演示路径A的方法和 过程这时就会遇到企业客户经常提出的问题一我们的公司到底需要几个中心？这些中心怎么出 来的？这些中心是什么样子？中台设计一般分两个阶段：业务中心分析和业务中心设计。
业务中心分析是从业务流程纷繁 复杂的业务场景出发分解出目标业务中心，业务中心设计需要完成中心的概要设计和详细设 计阶段1:业务中心分析这一步需要架构师具有深度的行业业务理解能力和软件分析设计能力，中台既是前台业务的 基石，也是衔接前后台业务的中枢，所以中台设计一定要从企业核心业务场景和流程出发第一步，识别整个体系中最核心的业务流程，如图4-3所示从这些流程出发，分析流程 中参与进来的关键业务和数据实体，一列举从核心到边缘，从前台到后台、从后台到前 台，正向流程、逆向流程，正常流程、异常流程，完整分析之后，你会得到一个企业业务实 体的全景图，这个图包括用户、会员、企业组织架构、商品、交易（批发、零售），等等这个过程做得越细越好在这个过程中，不要给自己设定用户中心、商品中心的概念，这时候你的眼里应该没有中心和业务系统的边界，只关注流程和实体本身流程梳理完全是从具 体业务场景出发，忠实于用户期望的业务需求，不要被现在实际的流程和系统所束缚图4-4展示了 O2O场景下一个线上下单、线下物流送货的处理流程中，把所有跨系统流程 全部梳理后得到的流程全景图第二步，把第一步分析的业务流程全景图聚合分析，从不同业务领域来归纳分析产生的业务 和数据实体。
这时你会发现，整个大图中最关键的那些业务实体与绝大多数的流程都有关 系，而且和绝大多数的业务场景都有交互通常，这时你所要找的适合纳入中台的业务领域 就呼之欲出了，比如会员域、商品域、交易域、库存域，等等这时就可以初步确定中台的基本轮廓图4-5是从上面梳理的业务流程全景图出发，分析流程中的主要业务对象，归类整理形成核心业务域，这些业务域将成为下一步服务中心设计的基础用户域订单域物流域c端用F*券域日端用户活动域线上店铺 线下门店§聚合核心分析业务域图4-5从业务流程中抗理川核心业务域A -1-4—_ LiiTslf - 芸j技力•顼TSi营销活动 貌程仃甲处理 流程财秀结算 流程核心流程集供应镒 流程庶存域第三步，对这些初步确定的业务域进行进一步分析，分析业务域相互之间的依赖关系、复杂 度、实体之间的亲密度等不同业务场景得到的结果可能大不一样，例如，有的企业积分营 销活动还不是很规范，也不成熟，在第一、二步的分析中可能会把积分账户放在会员域，因 为用户注册时会赠送初始积分，这是很自然的事情而有的企业营销活动非常成熟，会员消费行为会导致积分账户变化，同时积分营销活动又会 消费积分，所以会把积分账户放在交易域。
这一步需要基于一些服务化设计原则（参见后面的〃服务化设计原则”部分）把这种初筛后 的业务域的边界清晰化，有些需要把某些实体从A业务域放进B业务域；有时需要去伪存 真，把一些噪音型的对象剔除，让它们回归本来的前台或者后台；还有一些需要火眼金睛， 把本该进入但是却由于业务场景覆盖度不够暂时没有进入业务域的业务实体有预判性地拉进 来这一步需要架构师有丰富的分布式架构、服务化设计、中台设计的经验基于上一步的产出再用时序图的形式分析应用与业务域之间的关系，如图4-6所示，如果 做得细致一点，这个过程可以进一步细化出调用过程之中参与的业务实体注意，这里的时 序图是基于业务域得出的，不是旧有系统依赖关系的时序图分析业务规划中的业务场景和用例会产出完整的基于中台业务域架构的调用关系，再把这些 时序图按业务域进行分类归集时序图中和业务域的每一次交互算一次“触点”，按业务域把所有触点进行聚合，如图4-7所示，通过触点数我们可以直观地看出来这些“业务域” 的活跃度以及与业务场景的依赖程度这时可以结合上节介绍的判断标准、团队的资源以及 业务规划，定义出第一批可以升级到“中心”的业务域通过业务域与实体对象之间的依赖关系、业务域复杂度、业务实体之间的亲密度对业务域做 进一步的聚类，这样就可以将每一个业务实体归类到合适的业务域。
图主6应用与各业齐域的时序图祈以改货,通过这三个步骤，基本可以确定在当前规划的业务场景下，我们的中台到底应该有几个中 心，分别是哪些中心从业务调研得出中台服务中心的设计，这一步现在很多企业做得非常随意，一般都参考一些 互联网公司的实际经验或者基于自己对中台的理解，看到相关的流程就照搬过来，结果很可 能会“水土不服”在这里，我们推荐的方法是从企业的实际情况和具体需求出发，进行科 学分析，从客观分析中总结得来业务域中心用户域PO&系统交却域分销曾理系统官方商城/制信南城会员域第-：方电丽平台菅卸或WMS系统样存域QMS系疏FRM系统■■营销活动系统商乱域"刘点甑12-、r 艾付域:触点数：4)°一＞用户中心 r 5 卜一营箱中心 切一库存4」心＞一商品中心图4-7业•芳场眨到屯务域触点的梳理技未琐话阶段2:业务中心设计阶段1分析出了有几个中心以及中心边界，这一阶段要完成中心的详细设计工作在这个 阶段中，不是简单地根据业务需求划分模块后把这些模块落到中台层就是中台了，这样设计 出来的中台只是具体的业务模块下沉，缺乏抽象建模的过程，让中台的能力和扩展能力都非 常有限，这不能成为称职的中台业务中台一定要经历从具体到抽象的建模过程，中台设计 的核心是对业务抽象建模。
服务中心是业务中台最核心的架构元素，看起来和原来的应用系统的模块名称差不多，但是 在本质上提升了维度中心是拉通所有前后端系统的相关功能模块，进行统一抽象设计，用 一个统一的模型去支持前后台不同业务场景的需求，如图4-8所示我们从三个维度来描述一个完整的业务中心设计：业务模型、数据模型、服务能力，一个服 务中心通过业务模型描述业务承载逻辑，通过数据模型描述数据的底层规范，通过服务能力 描述服务接口契约通过这三个维度明确一个服务中心的设计，每个服务中心设计说明书要 产出这三个核心概念图4-9是一个会员中心的设计示例会员服务 等缓服务 收藏夹服务 轻社交服务服务诡力「社安运昔服苗 人社〔父功能服务 厂轻社攵管理服务 「收献火运营服务 A厂收藏*功能服务 「等级查询服务A厂等级管理服务「会况标签服务 入会：S功能服务 厂宫管理服务 会员服务能力<业务模型会员模型J厂——<.敬据模型会员库会处模型 会员标舱 会员等皴模型社交关系楔型 收敲火模型 微商等级模型 .会员 套员等级 收藏奏 社交关系图4-9服务中心设计的三个维度 '幻技才琐定：维度一：业务模型业务模型是一个比较难直接定义的概念，我们拿一个实际的例子来说明。
一家多业态经营的 房地产企业，旗下有传统的商业地产、住宅、物业，随着业务的拓展也有酒店、旅游门票， 甚至会发展出社区零售的业务如果这家企业选择中台架构，那么商品中心应该是什么样 子？ 从任何一个单一维度去看这家企业对商品的需求，可能差异都非常大，商业地产类的商品是 租售的铺位，住宅类的商品是商品房，物业是服务类商品，酒店和旅游门票是类似于电子凭 证类的虚拟商品，社区零售是通常意义上的百货商品我们对这些商品模型进行每种业务场 景的建模，都会面对这些模型的业务术语、模型结构，它们完全不一样地产商品属性特别 多，商品描述复杂但是模型结构单一，需要支持复杂组合查询；社区零售类商品种类会比较 多，变化比较快，用户并发量较高，商品描述结构都比较简单；酒店和旅游门票类商品要求 分类特别清晰，简单易管理如果基于〃烟囱式”架构来设计，针对这几种商品都可以推导出相应的模型如果用中台架 构，就需要对这几种业态的商品模型需求进行再一次抽象，用一个通用的模型支持多种场景 需求可以用主子类目来满足商品分类管理需求；用产品、属性、属性值、子属性来满足多 业态商品多样化描述需求；用标签来支持商品离散化管理需求；用前后台类目分离来满足基 于前台类目的营销和基于后台类目管理的需求。
通过这样的抽象，我们建立了如图4-10所 示的业务模型注意，基于这样的方法设计的业务模型，需要与上层业务对接的业务术语做一个统一比 如，对于地产类业务，如果原来是基于项目、分期、楼栋建立的树形结构，就要对应到现在 的类目体系上（对地产业态建立业务约束规范实现对接）；如果原来是社区零售业务，应该 对应到现在的商品类目管理体系下，这就是中台的业务模型商品偏于主数据模型结构，但是。