作为产品经理，你应该了解架构图！（1）架构图分了这8种！

架构图，架构师，一听就很高端的词汇是吧。

但说实话，其实也没啥，大多数情况下，都是装13用的。。。

作为产品经理，有这么几种架构图，你应该能够绘制，还有几种，你最起码应该了解！

来来来，先让我们用两张图说明一家伙，搞架构图的意义是什么。

那些上了年纪，没有搞过架构设计的代码，大概是这样的：

搞过架构设计的年轻代码，正常来说，应该是这样的：

可见，架构设计能达成的第一目标：简洁！

1. 设计人员

需求分析师、产品总监、产品经理

2. 概念和意义

业务架构关注的是组织的业务目标、流程和策略，它描述了组织的业务模型、价值链、业务流程和业务规则等。

业务架构能够帮助理解组织的核心业务，将业务需求转化为系统需求。

3. 使用场景

（1）产品规划和汇报会议上，产品人员可以用业务架构图来展现业务全局状态。

（2）对于技术经理级别的“程序猿”，在汇报的时候就不能光讲技术了，也要讲讲业务的发展情况，用业务架构图就能够比较容易地展现业务整体情况。

（3）给新员工培训业务的时候，你递给他几十页厚的文字介绍，再加上你的三寸不烂之舌，滔滔不绝，巴拉巴拉地讲了半天，然后他听完，只会觉困了甚至饿了。。。这个时候，一张业务架构图发给他，就能完美地解决问题！

4. 示例

（某集团管理系统业务架构图）

（滴滴平台业务架构图）

1. 设计人员

产品经理

2. 概念和意义

功能架构定义了系统的功能模块、组件和它们之间的关系。它描述了系统的功能分解和功能之间的依赖关系。

功能架构帮助理解系统的功能需求，将系统的功能划分为不同的模块或组件。

3. 使用场景

功能架构是对内的，是面向开发人员的，能够让开发人员对要开发的内容，有一个整体的认知。

4. 示例

（某支付系统功能架构图）

1. 设计人员

产品经理

2. 概念和意义

产品架构关注的是产品的整体结构和组织方式。它描述了产品的各个模块、功能和特性，并定义了它们之间的关系和交互方式。

产品架构定义了产品的整体结构和特性，考虑了市场需求、用户体验和竞争优势。

3. 使用场景

产品架构更多是对外的，是面向客户的。

尤其是对于B端产品来说，商务人员给客户介绍产品时，这个时候如果有个高端大气上档次的产品架构图，这一单说不定就成了！

4. 示例

1. 设计人员

架构师、技术经理

2. 概念和意义

应用架构关注的是系统中特定应用程序的结构和组织方式。它描述了应用程序的模块、组件、数据流和交互方式。

应用架构关注特定应用程序的设计和实现，满足系统的功能需求，其本质是通过系统拆分，平衡业务和技术复杂性，保证系统形散神不散一。

应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。分降低了业务复杂度，系统更有序，合增加了技术复杂度，系统更无序。

3. 使用场景

“程序猿”们，在开始动手写“BUG”之前，先搞个应用架构图，是非常有必要的！

系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特点；同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。

业务复杂性（包括业务量大)必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。

4. 示例

1. 设计人员

架构师、技术经理

2. 概念和意义

系统架构关注的是系统的整体结构和组织方式。它描述了系统的各个组件、模块、子系统以及它们之间的交互和通信方式。

系统架构定义了系统的整体结构和组织方式，考虑了系统的可扩展性、可靠性和安全性等方面的需求。

3. 使用场景

当然也是在“程序猿”们，正式写“BUG”之前，由大佬定义一下，到底该怎么开发。

应用架构，是从整体上定义了应用程序的实现方式。

系统架构，则是从更加具体的层面，对于应用程序怎样实现，进行了设计。

如果说应用架构，是“河南省”的规划，那么“系统架构”就是“郑州市”的规划。

4. 示例

1. 设计人员

架构师、技术经理

2. 概念和意义

技术架构定义了系统的技术基础设施和技术组件。它包括硬件、软件、网络、数据库等技术要素，并描述了它们之间的关系和交互方式。

技术架构提供了系统的技术实现方案，包括硬件、软件、网络和数据库等技术要素。

3. 使用场景

技术架构和系统架构的使用场景可以说是一致的。

而且很多时候，系统架构和技术架构，往往都是在一张图中体验，只不过二者的侧重点，略有不同，这个大家可以从“概念和意义”里面，再体会体会~

4. 示例

1. 设计人员

产品经理

2. 概念和意义

信息架构关注的是系统中信息的组织、分类和呈现方式。它描述了信息的结构、关系和导航方式。

信息架构组织和管理系统中的信息，帮助用户理解和浏览信息。

3. 使用场景

信息是面向业务的，主要是通过业务，梳理出来系统有哪些关键信息，并且通过这些信息，可以体现这款产品的哪些价值。

举个很简单的例子，产品中包含的信息，有一项是商机信息，就是有哪些用户，来访问公司的网站了，并且这些用户画像信息和行为信息，都能够及时推送给商务人员进行跟进。

那这不就是能帮公司挣钱么，试问哪个老板，不愿意为这么好的产品买单！

（上面的案例，就是我正在负责的产品，有哪个老板想要的，可以私聊我哦）

4. 示例

1. 设计人员

JAVA工程师、数据库工程师

2. 概念和意义

数据架构是为了指导数据库的设计，不仅仅要考虑开发中涉及到的数据库，实体模型，也要考虑物理架构中数据存储的设计。

数据架构关注持久化数据的存储方案，不仅包括实体及实体关系的存储格式、还包括数据传递，数据复制，数据同步等策略。

3. 使用场景

数据架构是面向技术的，可以在信息架构的基础上进行梳理。

4. 示例

其实绘制架构图和我们画原型真的差不多。

你见过哪个高保真原型，是通过axure的原生组件，一个“圆圈”，一个“方块”，一点一点地画出来的？

那不都是用“封装”好的，现成的各种组件，改吧改吧给搞出来的么~

我珍藏了多年的“PPT版”架构图，你看看想不想要？

一共有31张吧，先给大家来个总体预览：

再来挑几个典型，给大家演示一家伙~

好了，有需要PPT可编辑版本的，来通过下方二维码查看下载吧~

本篇文章来源于微信公众号: 晓庄同学产品笔记