关于产品架构

在日常工作中，我们常常会听到好几个架构，业务架构、信息架构和技术架构，这些和产品架构是什么关系呢？

1、业务架构往往是为了达到业务目标(通常是商业目标)所搭建的业务体系和商业模式，比如著名的亚马逊飞轮效应和Google搜索的印钞机模式。业务架构包括且不仅限于产品，产品架构是为了更好的支撑业务架构而构建的。

2、信息架构主要是产品在结构层的一部分，通常是在交互设计阶段考虑的产品给用户呈现的产品全貌，让用户可以清晰快速的找到功能的方法。有些说法会把产品架构和信息架构当成一回事，在一些2C产品里，从信息架构里就能看出产品架构，如新闻资讯类的app。但实际上信息架构只是产品架构的一种表现形式，并不能完全代表产品架构。

3、技术架构是产品架构的实现，并还覆盖有其他范畴，是个独立的大话题。在一些偏向技术型的产品里，产品架构和技术架构很接近，比如云计算产品，其用户本身就是程序员，所以云计算产品的产品架构和技术架构就非常接近了。

产品架构本身也有三个层次：

1、独立可交付客户价值的业务产品。

可独立交付价值的产品架构，这类架构往往和业务是强相关的，每个产品可以独立使用交付客户价值，形成采购，也可以针对客户不同场景的需求进行组合，提供综合解决方案。云计算产品就是最典型的例子，用户可以在云计算厂商官网根据自己的需求勾选一些产品，然后独立采购和使用。以视频云涉及到的几类常见产品：

对象存储。主要进行非结构化数据(文件)的存储。

CDN。内容分发网络，主要解决跨地域的海量用户资源访问速度的问题。

点播。主要是指音视频的播放问题，音视频会被转码成标准编码格式，并可通过指定播放器解码和播放。

直播。主要是实时音视频的直播，主要包括普通推流直播和实时互动直播。

对于客户而言：

如果只需存储海量数据，就只需要购买对象存储即可。

服务于不同地域的大量用户访问，就需要使用CDN。

类似于映客这样的直播类产品，就购买直播+CDN+对象存储。

像抖音、爱奇艺这种完整的视频类产品，就需要有直播+点播+CDN+对象存储。

2、单一产品内的模块化。

用户在一个较复杂产品里进行操作，其需求被满足的整个的流程会涉及到很多功能，其中这些功能可以进行分类，同一类功能组合成一个模块。因此一个复杂产品内部可以划分出多个模块，每个模块负责业务流中相似的一类功能。以淘宝为例，商家在淘宝上开店并发布商品，用户到淘宝上搜索到商品，下单购买。这一套业务流程里在淘宝这个超级app里，除了人机交互的那层壳以外，产品被划分成了用户中心、商品中心、交易中心、评价中心等几个模块。其中每个模块虽不能单独满足用户想要的商品购买的完整体验，但可以专注的解决购买过程中一类问题。而当这些模块抽象到能够服务淘宝以外其他的产品时，这就是中台了

3、单一个模块的抽象设计，也就是功能设计的架构。

即使是只满足一类需求的单模块，其在设计时也需要做好其架构。以在线考试模块为例，如果你对在线考试流程有一定的了解，就会大概想到整个过程。用户进入考试、完成题目并提交，系统判分，低于60分就未通过，超过80分就是优秀。如果仅仅只是做一个满足这个需求的在线考试系统，把细节再补充下，就可以直接出交互了。但前面我们也提到过了，产品经理在面对需求时要进行抽象，考虑到未来拓展的需求。那么我们就需要对此模块做架构设计和抽象拆解。首先，考试的核心价值是对通过一些设计好的题目去检验学生对知识点的理解情况，检验学生的最小的功能单元并不是试卷，而是题目。一道题目就完成了知识点的考核，和用户进行了价值交换。所以题目应该被抽象出来成为一个独立的子模块。通常一道题目会包括了题干、答案输入、标准答案、判题输出(对/错，答案解析)等部分，而从需求扩展的角度来看，在不同的年龄层次以及不同的学科里会有很多不同类型的题目，比如：

客观题：单选、多选、判断、填空等等

主观题，无标准答案，一般是大题，输入方式也有多种，有文字录入、画图、拍照录题等等

所以把题目这个结构抽象出来，有利于后期各种题型的拓展。试卷是整个系统性知识点检验的模块，是多个题目的组合。在题目的基础上，试卷还需要具备一些其他的能力，包括：

组卷规则，比如随机组卷，AB卷的能力

一些时间限制，开始作答、提交截止、答案公布等等

并且其实试卷只是一个抽象的概念，实际上试卷可以具象化成课后作业、小测验、考试等等多种使用形式交付给用户。