编辑导读：产品架构是对贸易模式中核心营业场景的抽象，是全部产品的“骨架”，表现了贸易模式的运作和实现方法。而对产品架构的设计是经由过程营业规矩来建立产品的内涵逻辑，是产品工作中重要的一环。本文作者根据自身工作经验，分享了一些产品架构设计办法与核心设计原则，欲望对你有赞助。
一、什么是产品架构
产品架构是对贸易模式中核心营业场景的抽象，表现了贸易模式的运作和实现方法，产品架构设计是抽象营业场景，经由过程营业规矩建立产品内涵逻辑的过程。
二、以X产品为例介绍产品架构分层
如下图所示，起首对X产品做一个背景介绍，如今要设计一个电商平台X，今朝只支撑自营营业，并且一部分体系已存在（支撑后台及其办事）。
图中总共包含4部分： 应用层、办事层、技巧架构层、支撑后台。个中，产品架构重要涉及的是应用层、办事层、支撑后台，技巧架构层是一个简化的技巧架构，添加其目标是为了展示一个全景，让大年夜家懂得一下与产品架构与技巧架构的关系。
应用层和办事层表现了“小前台、大年夜中台”的计谋思惟，是产品架构的核心。当然，并不是说没有中台就没有产品架构，只是这是当前主流的产品架构。假如没有中台，办事层就是纯真的API，就须要把这部分的办事才能提到应用层里，在此不做介绍。
产品架构与技巧架构层的关系：
应用层、办事层、逻辑层、数据层，4层表现了技巧上MVC框架的设计思惟，是一个逻辑递进关系，越往底层走越偏向技巧实现。
技巧架构可以划分的很细，在此不做具体解释，重要介绍技巧实现道理：应用层经由过程一次用户操作获取数据，然后经由过程办事层把数据传输到逻辑层，逻辑层经由过程代码实现的规矩对数据层数据进行处理，处理完之后再反向通知到应用层，反馈给用户，如许也就实现了一次用户交互。
三、具体介绍X产品的产品架构构成
先解释下“应用层（小前台）”和“办事层（大年夜中台）”中“大年夜小”的意思，“小前台”其实并不是真的小，只是相对中台小罢了，因为中台包含的办事特别多（假如不睬解办事的意思，可以把“办事”改成“才能”），承载的营业也丰富，而不合前台产品都是有不合定位的，可能一个中台办事于十几甚至几十个产品，所以就是小前台、大年夜中台。
那么前台到底是什么？大年夜家应当对阿里中台计谋有所懂得，假如用阿里的产品矩阵来距离的话，就包含了天猫、淘宝、菜鸟物流、1688等等，然则这部分只是面向前台用户的产品，其实还有对应产品的后台，可能面向各类商家，也可能面向内部治理，这些后台对中台来说也都是前台。说白了，只如果由中台供给办事的产品或体系，对中台来说都是它的前台。
这里存在一个误区，就是很多人认为中台在前台和后台之间，那就要分清“后台”到底是名字上有“后台”，实际是一个由中台供给办事的前台，照样产品线上用于支撑该产品的后台产品。这也就是为什么“平台后台”会涌如今“小前台”的原因了。
应用层包含了各类各样的前台，不合形态的产品，可能是App端、Web/PC端、H5、小法度榜样，这些不合形态的产品可能面向2C也可能面向2B。
办事层重要包含两部分：基本办事（或者叫内部办事）和外部办事。
基本办事就是要完成X产品须要设计的办事，外部办事就是已经存在于其他产品，可以直接应用的办事（该图的表里办事不代表实际设计时的划分，要根据实际情况划分，数据中台也不是必须的，在这里占了个坑）。
办事中间供给的基本办事可以零丁对应用层供给办事，也可以跟外部办事进行组合，形成一个新的办事，对应用层供给办事。
对办事本身的设计不属于产品设计范畴，然则为了可以或许懂得产品内涵的逻辑，都要对办事有所懂得，这是中后台产品经理的核心才能之一，我会在后面做简单介绍。
支撑后台分为两部分：可直接供给外部办事的后台体系和支撑X产品数据流转的后台体系。
在此解释两个概念：
- 办事产品化：当办事层的才能越来越强时，就可以把不合的办事组合，打包成一个新的产品供给给愿意为其买单的用户。图中CRM就是办事产品化的成果。
- 产品办事化：当自身的产品做到极致，并且很多其他企业也想要拥有这种才能时，就须要把自身的才能开放出去，然后就出现了“开放平台”，这是一个典范的开放才能的产品。在开放平台里，有企业内各类各样的产品才能，其他企业可以经由过程对应的API获取到对应的才能，比如付出、地图，这就是把付出产品和地图产品办事化了。
X产品的产品架构图可以简化成下面如许（办事中间内的内容表现了其可支撑的营业才能，在画整体架构图时可以简化掉落）：
根据上图来分析产品架构的设计办法（以下为一步步细化的过程）：
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协定。
- 上一篇： 国商信联财富：好的开场白是成功的一半
- 下一篇： 卖药APP背后的大生意
