抽象化服务中心的边界，确认其可提供的业务能力

确定当前产品与其他产品的关系

该产品与哪些前台产品有关系？是否涉及到建设中台服务？哪些服务是可以直接用的？哪些是需要新建的？数据是否流转到其他系统？

也就是把三层涉及的产品关系梳理出来

2）梳理涉及的业务场景与功能模块

分析产品在各个业务场景下需要什么功能支撑，此处不需要像做前台产品详细设计时分析的那么细致。

3）抽象化服务中心的边界，确认其可提供的业务能力

根据第二步中涉及的实际业务划分服务中心（也有称呼叫“子系统”或“服务领域”之类的），并把能提供的核心业务能力填充到服务中心（划分的原则后面介绍）。

4）将业务能力抽象出业务实体，转化为支持前台功能的服务

其实把前三步梳理清楚，整体的产品架构也就出来了，这一步主要是为了详细设计单个服务中心内部的架构，这一步既体现出了你对业务的理解力，也体现出了你对产品真正的设计能力。

以下以促销中心为例做分析：

先把各种方式的促销业务流程画出来，如下图所示，可以看出，前五种促销的整体流程都是一致的，只是促销的方式和条件不同。而优惠券却跟促销不同，而且流程上并不兼容，所以促销中心抽象出两个业务实体：促销活动、优惠券。

有了实体以后，最标准的基础服务就是对实体的“增删改查”，以下为促销中心的产品架构图（包含了跟其他服务中心的服务关系） ，如下图所示，什么“满减、满赠、立减”已经消失了。

通过这几步细化下来，也就对服务与服务的关系，服务与产品的关系比较明确了。这样在做产品设计时，根据实际的业务设计前台功能就行了，端到端考虑每个产品应该如何设计。

五、因产品增加导致架构变化示例

按上面的思路来分析，现在X要支持其他商家入驻到平台销售商品，而且要做一个CRM产品，就形成了如图所示的X产品体系的产品架构图：

通过图中添加的绿色字体部分可以看出，因为业务范围扩大了，所以补充了对应的商家中心，而且平台后台变成了商家后台，虽然新增了一个CRM，但是服务层并没有变化。中台在新的业务到来时在进化（增加了商家中心），而在支撑一个新的产品时中台却可以不变，因为在整体架构设计上中台已经支持了多前台，除非新的前台有特殊需求，这就体现了“小前台、大中台”的灵活性。

在此，解释另外一个概念：

SaaS（软件即服务）： X产品刚开始用户量很小，但用户量大增后需要做一个新产品“CRM”用于管理用户。如果这个CRM是给平台管理全部2C用户的产品，就是一个平台级“CRM”，如果这个CRM是给所有2B客户单独管理自己的2C用户，那么这就是一个“SaaS CRM”。SaaS的关键特点是数据隔离，虽然各个商家用的同一个产品，但是不同商家的数据不共享。钉钉、企业微信都是典型的SaaS产品。

六、服务划分和核心设计原则

最后回顾一下整体架构图，来看一下服务的划分和设计原则：