8种架构图设计.pdf

8种架构图设计

1业务架构图

1.设计人员

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

2.概念和意义

业务架构关注的是组织的业务目标、流程和策略，它描述了组织的业务模型、

价值链、业务流程和业务规则等。

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

3.使用场景

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

态。

（2）对于技术经理级别的“程序猿”，在汇报的时候就不能光讲技术了，也要讲

讲业务的发展情况，用业务架构图就能够比较容易地展现业务整体情况。

（3）给新员工培训业务的时候，你递给他几十页厚的文字介绍，再加上你的

三寸不烂之舌，滔滔不绝，巴拉巴拉地讲了半天，然后他听完，只会觉困了甚

至饿了。。。这个时候，一张业务架构图发给他，就能完美地解决问题！

4.示例

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

（滴滴平台业务架构图）

2功能架构图

1.设计人员

产品经理

2.概念和意义

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

能分解和功能之间的依赖关系。

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

3.使用场景

功能架构是对内的，是面向开发人员的，能够让开发人员对要开发的内容，有

一个整体的认知。

4.示例

155

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

3产品架构图

1.设计人员

产品经理

2.概念和意义

产品架构关注的是产品的整体结构和组织方式。它描述了产品的各个模块、功

能和特性，并定义了它们之间的关系和交互方式。

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

势。

3.使用场景

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

尤其是对于B端产品来说，商务人员给客户介绍产品时，这个时候如果有个高

端大气上档次的产品架构图，这一单说不定就成了！

4.示例

4应用架构图

1.设计人员

架构师、技术经理

2.概念和意义

应用架构关注的是系统中特定应用程序的结构和组织方式。它描述了应用程序

的模块、组件、数据流和交互方式。

应用架构关注特定应用程序的设计和实现，满足系统的功能需求，其本质是通

过系统拆分，平衡业务和技术复杂性，保证系统形散神不散一。

应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。

分降低了业务复杂度，系统更有序，合增加了技术复杂度，系统更无序。

3.使用场景

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

系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特

点；同时受技术复杂性影响，包括IT技术发展阶段和内部技术人员水平。

业务复杂性（包括业务量大)必然带来技术复杂性，应用架构目标是解决业务复

杂性的同时，避免技术太复杂，确保业务架构落地。

4.示例

5系统架构图

1.设计人员

架构师、技术经理

2.概念和意义

系统架构关注的是系统的整体结构和组织方式。它描述了系统的各个组件、模

块、子系统以及它们之间的交互和通信方式。

系统架构定义了系统的整体结构和组织方式，考虑了系统的可扩展性、可靠性

和安全性等方面的需求。

3.使用场景

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

发。

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

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

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

4.示例

6技术架构图

1.设计人员

架构师、技术经理

2.概念和意义

技术架构定义了系统的技术基础设施和技术组件。它包括硬件、软件、网络、

数据库等技术要素，并描述了它们之间的关系和交互方式。

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

要素。

3.使用场景

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

而且很多时候，系统架构和技术架构，往往都是在一张图中体验，只不过二者

的侧重点，略有不同，这个大家可以从“概念和意义”里面，再体会体会~

4.示例

7信息架构图

1.设计人员

产品经理

2.概念和意义