经典数字化转型案例，一文通解架构设计流程及方法（下）：经典数字化转型案例

原标题：经典数字化转型案例，一文通解架构设计流程及方法（下）
上篇阶段1分析出了有几个中心以及中心边界，这一阶段要完成中心的详细设计工作。在这个阶段中，不是简单地根据业务需求划分模块后把这些模块落到中台层就是中台了，这样设计出来的中台只是具体的业务模块下沉，缺乏抽象建模的过程，让中台的能力和扩展能力都非常有限，这不能成为称职的中台。业务中台一定要经历从具体到抽象的建模过程，中台设计的核心是对业务抽象建模。

文章图片
服务中心是业务中台最核心的架构元素，看起来和原来的应用系统的模块名称差不多，但是在本质上提升了维度。中心是拉通所有前后端系统的相关功能模块，进行统一抽象设计，用一个统一的模型去支持前后台不同业务场景的需求，如图4-8所示。

文章图片
我们从三个维度来描述一个完整的业务中心设计：业务模型、数据模型、服务能力，一个服务中心通过业务模型描述业务承载逻辑，通过数据模型描述数据的底层规范，通过服务能力描述服务接口契约。通过这三个维度明确一个服务中心的设计，每个服务中心设计说明书要产出这三个核心概念。图4-9是一个会员中心的设计示例。

文章图片
维度一：业务模型
业务模型是一个比较难直接定义的概念，我们拿一个实际的例子来说明。一家多业态经营的房地产企业，旗下有传统的商业地产、住宅、物业，随着业务的拓展也有酒店、旅游门票，甚至会发展出社区零售的业务。如果这家企业选择中台架构，那么商品中心应该是什么样子？
从任何一个单一维度去看这家企业对商品的需求，可能差异都非常大，商业地产类的商品是租售的铺位，住宅类的商品是商品房，物业是服务类商品，酒店和旅游门票是类似于电子凭证类的虚拟商品，社区零售是通常意义上的百货商品。我们对这些商品模型进行每种业务场景的建模，都会面对这些模型的业务术语、模型结构，它们完全不一样。地产商品属性特别多，商品描述复杂但是模型结构单一，需要支持复杂组合查询；社区零售类商品种类会比较多，变化比较快，用户并发量较高，商品描述结构都比较简单；酒店和旅游门票类商品要求分类特别清晰，简单易管理。
如果基于“烟囱式”架构来设计，针对这几种商品都可以推导出相应的模型。如果用中台架构，就需要对这几种业态的商品模型需求进行再一次抽象，用一个通用的模型支持多种场景需求。可以用主子类目来满足商品分类管理需求；用产品、属性、属性值、子属性来满足多业态商品多样化描述需求；用标签来支持商品离散化管理需求；用前后台类目分离来满足基于前台类目的营销和基于后台类目管理的需求。通过这样的抽象，我们建立了如图4-10所示的业务模型。
注意，基于这样的方法设计的业务模型，需要与上层业务对接的业务术语做一个统一。比如，对于地产类业务，如果原来是基于项目、分期、楼栋建立的树形结构，就要对应到现在的类目体系上（对地产业态建立业务约束规范实现对接）；如果原来是社区零售业务，应该对应到现在的商品类目管理体系下，这就是中台的业务模型。
商品偏于主数据模型结构，但是不要因此就误以为服务中心的模型都是主数据模型，交易时要统一交易流程，营销时要统一规则：针对不同的业务领域，有不同的建模诉求；基于业务但一定要高于业务。如果做不到模型层面的抽象统一，那就只是具体业务形态的模块下沉，中台的价值难以发挥。

文章图片
维度二：数据模型
数据模型是服务中心底层的数据层实现，包括OLTP和OLAP两种场景。根据业务的需求，可能需要结合分布式数据库技术。与交易相关的业务场景中，最常见的数据模型方案是定义实体关系模型，如果对扩展性有要求，则可结合分布式数据库技术形成方案。数据模型的第一个职责是明确数据的业务规范，为业务数据化和数据中台建设做好基础准备工作。
维度三：服务能力