第三步，对这些初步确定的业务域进行进一步分析，分析业务域相互之间的依赖关系、复杂度、实体之间的亲密度等。不同业务场景得到的结果可能大不一样，例如，有的企业积分营销活动还不是很规范，也不成熟，在第一、二步的分析中可能会把积分账户放在会员域，因为用户注册时会赠送初始积分，这是很自然的事情。
而有的企业营销活动非常成熟，会员消费行为会导致积分账户变化，同时积分营销活动又会消费积分，所以会把积分账户放在交易域。
这一步需要基于一些服务化设计原则（参见后面的“服务化设计原则”部分）把这种初筛后的业务域的边界清晰化，有些需要把某些实体从A业务域放进B业务域；有时需要去伪存真，把一些噪音型的对象剔除，让它们回归本来的前台或者后台；还有一些需要火眼金睛，把本该进入但是却由于业务场景覆盖度不够暂时没有进入业务域的业务实体有预判性地拉进来。这一步需要架构师有丰富的分布式架构、服务化设计、中台设计的经验。
基于上一步的产出再用时序图的形式分析应用与业务域之间的关系，如图4-6所示，如果做得细致一点，这个过程可以进一步细化出调用过程之中参与的业务实体。注意，这里的时序图是基于业务域得出的，不是旧有系统依赖关系的时序图。
分析业务规划中的业务场景和用例会产出完整的基于中台业务域架构的调用关系，再把这些时序图按业务域进行分类归集。时序图中和业务域的每一次交互算一次“触点”，按业务域把所有触点进行聚合，如图4-7所示，通过触点数我们可以直观地看出来这些“业务域”的活跃度以及与业务场景的依赖程度。这时可以结合上节介绍的判断标准、团队的资源以及业务规划，定义出第一批可以升级到“中心”的业务域。
通过业务域与实体对象之间的依赖关系、业务域复杂度、业务实体之间的亲密度对业务域做进一步的聚类，这样就可以将每一个业务实体归类到合适的业务域。
通过这三个步骤，基本可以确定在当前规划的业务场景下，我们的中台到底应该有几个中心，分别是哪些中心。
从业务调研得出中台服务中心的设计，这一步现在很多企业做得非常随意，一般都参考一些互联网公司的实际经验或者基于自己对中台的理解，看到相关的流程就照搬过来，结果很可能会“水土不服”。在这里，我们推荐的方法是从企业的实际情况和具体需求出发，进行科学分析，从客观分析中总结得来。
阶段2：业务中心设计
阶段1分析出了有几个中心以及中心边界，这一阶段要完成中心的详细设计工作。在这个阶段中，不是简单地根据业务需求划分模块后把这些模块落到中台层就是中台了，这样设计出来的中台只是具体的业务模块下沉，缺乏抽象建模的过程，让中台的能力和扩展能力都非常有限，这不能成为称职的中台。业务中台一定要经历从具体到抽象的建模过程，中台设计的核心是对业务抽象建模。
服务中心是业务中台最核心的架构元素，看起来和原来的应用系统的模块名称差不多，但是在本质上提升了维度。中心是拉通所有前后端系统的相关功能模块，进行统一抽象设计，用一个统一的模型去支持前后台不同业务场景的需求，如图4-8所示。
我们从三个维度来描述一个完整的业务中心设计：业务模型、数据模型、服务能力，一个服务中心通过业务模型描述业务承载逻辑，通过数据模型描述数据的底层规范，通过服务能力描述服务接口契约。通过这三个维度明确一个服务中心的设计，每个服务中心设计说明书要产出这三个核心概念。图4-9是一个会员中心的设计示例。
维度一：业务模型
业务模型是一个比较难直接定义的概念，我们拿一个实际的例子来说明。一家多业态经营的房地产企业，旗下有传统的商业地产、住宅、物业，随着业务的拓展也有酒店、旅游门票，甚至会发展出社区零售的业务。如果这家企业选择中台架构，那么商品中心应该是什么样子？
从任何一个单一维度去看这家企业对商品的需求，可能差异都非常大，商业地产类的商品是租售的铺位，住宅类的商品是商品房，物业是服务类商品，酒店和旅游门票是类似于电子凭证类的虚拟商品，社区零售是通常意义上的百货商品。我们对这些商品模型进行每种业务场景的建模，都会面对这些模型的业务术语、模型结构，它们完全不一样。地产商品属性特别多，商品描述复杂但是模型结构单一，需要支持复杂组合查询；社区零售类商品种类会比较多，变化比较快，用户并发量较高，商品描述结构都比较简单；酒店和旅游门票类商品要求分类特别清晰，简单易管理。
如果基于“烟囱式”架构来设计，针对这几种商品都可以推导出相应的模型。如果用中台架构，就需要对这几种业态的商品模型需求进行再一次抽象，用一个通用的模型支持多种场景需求。可以用主子类目来满足商品分类管理需求；用产品、属性、属性值、子属性来满足多业态商品多样化描述需求；用标签来支持商品离散化管理需求；用前后台类目分离来满足基于前台类目的营销和基于后台类目管理的需求。通过这样的抽象，我们建立了如图4-10所示的业务模型。
注意，基于这样的方法设计的业务模型，需要与上层业务对接的业务术语做一个统一。比如，对于地产类业务，如果原来是基于项目、分期、楼栋建立的树形结构，就要对应到现在的类目体系上（对地产业态建立业务约束规范实现对接）；如果原来是社区零售业务，应该对应到现在的商品类目管理体系下，这就是中台的业务模型。
商品偏于主数据模型结构，但是不要因此就误以为服务中心的模型都是主数据模型，交易时要统一交易流程，营销时要统一规则：针对不同的业务领域，有不同的建模诉求；基于业务但一定要高于业务。如果做不到模型层面的抽象统一，那就只是具体业务形态的模块下沉，中台的价值难以发挥。
维度二：数据模型
数据模型是服务中心底层的数据层实现，包括OLTP和OLAP两种场景。根据业务的需求，可能需要结合分布式数据库技术。
与交易相关的业务场景中，最常见的数据模型方案是定义实体关系模型，如果对扩展性有要求，则可结合分布式数据库技术形成方案。数据模型的第一个职责是明确数据的业务规范，为业务数据化和数据中台建设做好基础准备工作。
维度三：服务能力
服务能力是中台业务能力对外的服务契约，外部系统通过接入中台的服务来使用中台。服务列表包括两部分：第一部分是针对中心的外部用户部分，这部分要明确服务的接口契约，包括使用的通信协议、安全鉴权方案、服务的请求报文和响应报文、服务的具体业务含义以及调用的上下文、异常情况等；第二部分是服务的开发实现，这部分内容需要设计者画出服务的业务流程、业务边界、异常处理等。
上面已经完成了中台的设计，在进入具体的开发之前，为了保证设计的中台模型能满足真实的业务场景，最好将中台的服务放入具体的业务流程中进行验证，也可以基于服务的mock实现来进行验证。这个过程可能比较烦琐，但是通过这个验证过程，可以发现中台的业务模型抽象是否正确，使用是否方便，服务是否完整，发现设计中模型的问题，再快速迭代修改。如果所有的业务场景都能通过这样的验证，那么中台的设计方案是可行的。
（4）开发实现
开发实现基于服务接口规范、数据模型和业务流程进行，当数据模型和服务能力都具备后，开发者就能进行详细设计和开发了。这里并没有特殊之处，但需要开发人员掌握分布式、服务化相关的一些开发原则和技术，特别是在分布式体系下，引入了一些在传统一体化架构体系下不太关注的技术原则，比如分布式事务、异步、幂等问题。相关技术可参考《企业IT架构转型之道》一书。
本文由机械工业出版社独家授权发布，中台圣经——《企业IT架构转型之道》作者钟华新作！《数字化转型的道与术：以平台思维为核心支撑企业战略可持续发展》。
十余年数字化实战经验再升华！开创性提出数字化转型中平台思维的十大要素。来自实践，并能指导实践。系统化介绍数字化转型的思路与方法，以及产业互联网平台的建设思路，为各种业务模式的数字化转型提供高价值参考。
