编辑导读：产品架构是业务模型中核心业务场景的抽象，是整个产品的“骨架”，体现了业务模型的运行和实现。产品架构的设计是通过业务规则建立产品的内部逻辑，是产品工作的重要组成部分。笔者根据自己的工作经验，分享了一些产品架构的设计方法和核心设计原则，希望对大家有所帮助。

一、什么是产品架构

产品架构是业务模型中核心业务场景的抽象，反映了业务模型的运行和实现。产品架构设计是通过业务规则抽象业务场景，建立产品内部逻辑的过程。

00-1010如下图所示，首先给X产品一个背景介绍。现在需要设计一个电商平台X，目前只支持自营业务，部分系统已经存在(支持后台及其服务)。

图中有四个部分：应用层、服务层、技术架构层和支撑背景。其中，产品架构主要涉及应用层、服务层和支撑后台。技术架构层是一个简化的技术架构，它的加入是为了展现一个全景，让大家了解与产品架构和技术架构的关系。

应用层和服务层体现了“小前台、大中平台”的战略思想，是产品架构的核心。当然，并不代表没有中间平台就没有产品架构，而是目前主流的产品架构。如果没有中间平台，服务层就是一个简单的API，所以需要把这部分服务能力带到应用层，这里就不介绍了。

产品架构和技术架构层之间的关系：

应用层、服务层、逻辑层和数据层在技术上体现了MVC框架的设计思想，是一种逻辑递进关系。层越低，越倾向于技术实现。

技术架构可以分为非常精细的部分，这里就不详细解释了。我主要介绍技术实现的原理：应用层通过用户操作获取数据，然后通过服务层将数据传输到逻辑层，逻辑层通过代码实现的规则对数据层中的数据进行处理，处理后将应用层通知回用户，从而实现用户交互。

00-1010我们先来解释一下“应用层(小型前台)”、“服务层(大中型站)”中“规模”的含义。“小前台”其实并不算小，但相对于中站来说还是比较小的，因为中站包含了很多服务(如果不理解服务的含义，可以把“服务”改成“能力”)，它承载的服务也是。

那么前台到底是什么？大家应该对阿里的中台战略略知一二。如果用阿里的产品矩阵做距离的话，包括天猫、淘宝、菜鸟物流、1688等。但这部分只是面向前端用户的产品。其实对应的产品都有后端，可能是针对各种业务或者内部管理。这些后端也是中台的前端。说白了，只要是中国中心站提供的产品或系统，就是它为中国中心站提供的前台。

这里有一个误区，就是很多人认为中间阶段介于前阶段和后阶段之间，所以要区分“后阶段”是不是有“后阶段”这个名称，实际上是中间阶段提供的前阶段还是用来支撑产品线上产品的后阶段产品。这就是为什么“平台后台”出现在“小前台”的原因。

应用层包括各种前台、不同形态的产品，可以是App、Web/PC、H5、小程序。这些不同形态的产品可能面向2C或2B。

服务层主要由两部分组成：基础服务(或内部服务)和外部服务。

基础服务是需要为X产品设计的服务，外部服务是其他产品中已经存在的可以直接使用的服务(此图中的内部和外部服务不代表实际设计中的划分，应该根据实际情况来划分，数据的中间平台

服务中心提供的基础服务可以单独向应用层提供服务，也可以与外部服务结合形成新的服务向应用层提供服务。

服务本身的设计并不属于产品设计的范畴，但要理解产品的内在逻辑，就要对服务有所了解，服务是中后台产品经理的核心能力之一，后面我会简单介绍。

支撑后台分为两部分：可以直接提供外部服务的后台系统和支持X产品数据流的后台系统。

这里解释了两个概念：

产品化：当服务层的能力越来越强的时候，不同的服务组合就可以打包成一个新的产品给愿意付费的用户。图中的CRM是服务产品化的结果。面向服务：当自己的产品达到极致，其他很多企业都想拥有这种能力，就需要开放自己的能力，于是就出现了“开放平台”，这是一个典型的开放能力的产品。在开放平台中，企业内部有各种各样的产品能力，其他企业可以通过相应的API获得相应的能力，比如支付和地图，这就是支付产品和地图产品的服务。

00-1010x产品的产品架构图可以简化如下(服务中心的内容反映了其可支持的业务能力，在绘制整体架构图时可以简化):

根据上图分析产品架构的设计方法(以下是详细的分步流程):

1)确定当前产品与其他产品之间的关系

该产品与哪些前端产品相关？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1）服务重在定边界，遵循高内聚、低耦合原则

高内聚是从服务中心的业务来说的，在一个服务中心内的业务应该是相关性和依赖性很高的；而服务中心之间应该是业务隔离性比较大的，即追求尽可能的低耦合。

2）服务抽象化，尽量通用

抽象是从众多的事物中抽取出共同的、本质性的特征，而舍弃其非本质的特征的过程。将业务能力转化成对应的业务实体就是抽象的过程，即对相同或相似的业务能力提取出共性的特征，抽象出可以提供给不同前台的公共服务，尽量做到服务通用，个性化需求由不同的前台实现。

3）可扩展性

在服务的设计时不能只满足当前业务需求，还要考虑服务对未来业务的支撑，这样可以减少未来对服务的修改。比如说对商品品类层级的设计，理论上来说可以无限层级扩展，但是考虑到前台的易用性和实际应用，不会设计很多层级也不会只有一层，而三级就能满足绝大部分业务场景了。所以在设计时也要注意另外一个原则：不过度设计。

4）可复用性

即服务可以多次重复使用，服务的抽象化程度高，可复用性也会越强。在支撑新的业务能力时，优先看是否存在可以复用的服务，如果没有，再考虑现有服务是否可以通过改造（再次抽象服务或扩展服务能力）达到这一目标，最后才考虑设计新的服务。

5）渐进性建设

渐进性的建设原则是从降低风险和实施难度这个角度出发，推荐小步快跑的方式逐步推进，而不是轰轰烈烈地推翻重来，试错的成本更低。

本文由 @Zurl 原创发布于人人都是产品经理，未经允许，禁止转载

题图来自Unsplash，基于CC0协议。