产品架构图是什么？模块、层级、依赖与产品族绘制指南

产品架构图把产品拆成职责清楚的模块，展示它们的层级、依赖和边界。画图的重点不是把所有功能排满一页，而是让团队回答三个问题：一个用户任务经过哪些模块，谁对每个模块负责，改动一个模块会影响哪里。

用在线架构图工具梳理模块时，先选定一次具体评审要解决的问题。本文以会员积分商城为主线，说明功能、关系和产品族如何表达；数据库选型、服务部署等实现细节应交给对应技术视图。

• 架构图定义与类型
• 技术架构图绘制方法
• 架构图模板大全

1. 产品架构图是什么

产品架构图是对产品组成及关系的可视化表达。它通常围绕用户角色、业务能力、功能模块和外部依赖组织内容，让产品、研发和业务方对“做什么、由谁提供、如何衔接”形成一致理解。

矩形可以表示模块，分组框表示层级或产品边界，箭头表示依赖、调用或信息传递。关键是为箭头写清含义：同一张图里，不能一条线表示“包含”，另一条外观相同的线却表示“发送订单”。包含关系优先用分组框，流程先后另画流程图。

产品规划评审看能力是否齐全，需求评审看职责是否重叠，跨产品协作看哪些能力共享。排查服务器故障则需要更细的技术架构与监控信息，不能仅凭产品架构图完成。

下图的数据平台把应用、数据中台和数据来源分层呈现。阅读时先看每层承担什么职责，再决定自己的产品是否需要这些层级；会员积分商城不必照搬数据平台的全部组件。

2. 产品架构图构成要素有哪些

画一张面向产品评审的架构图，先写角色、模块、层级、依赖和范围。技术栈只有在它影响产品边界或集成约束时才需要出现，不必在每个功能框下面都写数据库或开发语言。

• 核心组件与模块

模块应以业务职责命名，如会员身份、积分账户、商品兑换、兑换订单和运营配置。为每个模块写一句“负责什么、不负责什么”，比先列用户界面、数据库、API更容易发现产品边界。

• 层级关系与交互逻辑

层级表示能力怎样组织，连线表示模块之间的关系。积分商城可以按用户入口、交易能力、共享能力来分组；订单向积分账户请求扣减，应标明方向与目的，而不是画一根没有说明的线。

• 技术栈标注

只有确定的技术约束才标注。例如积分账户由现有会员平台提供、兑换订单要接入外部库存系统，这些约束会影响依赖关系。React或MySQL等实现选择若与本次产品评审无关，可在技术架构图中单独维护。

• 用户角色与权限

角色决定谁能操作什么。会员查看自己的积分与兑换记录，运营人员配置商品和兑换规则，客服处理异常订单；不同角色不应因画在同一张图上就被默认拥有全部权限。

• 外部依赖与第三方服务

外部系统用边界框区分，写明由哪一方维护、提供什么能力，以及不可用时如何处理。纯积分兑换若不涉及现金，就不必为了“完整”加入支付模块；只有积分加现金场景才需要评估支付依赖。

下图的履约产品架构把订单接入、规则管理、履约决策、调度、监控和异常处理放在不同区域。它提示一个容易漏掉的点：架构除了正常路径，还要给异常处理留出明确责任，不能只画“创建成功”。

3. 产品架构图的常见类型与相邻视图

（1）功能架构图

功能架构图聚焦产品功能模块划分，以树状或模块化的形式展示功能点及其从属关系。其用于产品功能清单的梳理，帮助团队明确功能范围，避免遗漏或冗余。常见的使用场景有需求评审阶段，如电商平台的购物车、支付、物流模块。

查看功能架构图模板

（2）业务架构图

业务架构图以业务功能为核心，通常采用分层或分组的方式展示业务模块的关联性。它帮助企业部门梳理业务逻辑和需求，支持战略决策和跨部门沟通。在产品规划中，展示多系统间的业务协同关系；新产品立项时，明确业务边界和功能范围。

查看业务架构图模板

（3）信息架构图

信息架构图侧重内容分类、导航和用户查找路径。积分商城可以用它安排“积分明细、可兑换商品、我的订单”等入口；订单和积分服务怎样交换数据，属于模块交互或技术设计，不能与导航结构混在一起。

（4）技术架构图

技术架构图描述系统组件、接口、部署或技术约束，为研发实现提供依据。产品图中的一个“积分账户”模块，可能在技术图里展开为多个服务和数据存储。两张图应可对应，但不必用相同的细节层级。

产品族怎么画：共享能力只维护一份

当同一产品有多个版本，或多个产品共用一套能力时，可以增加产品族视角。比如会员中心、积分商城和营销活动都使用会员身份，积分商城与营销活动共同使用积分账户。把共享模块画在独立区域，再连接到需要它的产品；不要复制三份相同模块，制造“每个产品各有一套数据”的错觉。

矩阵表达的是能力使用关系，不是数据库访问权限。是否共享实现、接口如何隔离，仍要由技术方案确认。

查看技术架构图模板

4.  产品架构图怎么画

第1步：明确绘制目的与范围

先在画布写明：“本次评审会员使用积分兑换实物商品的第一版，包含兑换与取消，不含积分加现金、跨境配送及活动推荐。”这句话会决定后面哪些模块必须有、哪些应留在范围外。准备材料包括用户角色、兑换规则、订单状态和已确定的外部接口。

• 界定绘图目的：规划新产品时先覆盖整体功能边界；用于产品迭代时，重点展示需调整的模块与受影响的依赖。不要把所有细节都放进一张总览图。
• 确定产品架构图的范围：明确所涉及的业务领域、产品线以及功能边界。

第2步：梳理产品功能模块

分析产品，拆分功能模块，确定目标用户群体，思考用户在使用产品过程中的各项操作及需求，进而提炼出对应的功能模块。

在Boardmix中先放三块区域：顶部“会员／运营／客服”，中间“商品兑换／兑换订单”，下方“会员身份／积分账户／通知”。外部库存单独放在右侧边界框里。每个模块下面写一句职责，再按上表检查是否有人同时修改同一份业务事实。

如果商品兑换模块和订单模块都写了“扣积分”，先停下来澄清：谁发起请求、谁拥有积分余额、谁记录结果。未解决职责重叠前，不急着用颜色装饰。

第3步：确定模块关系

分析各模块关系，包括业务流程关系，也就是在实际业务操作中，各功能模块的先后执行顺序；以及依赖关系，某些模块的正常运行是否依赖其他模块的输出或状态。

这里采用“冻结积分—占用库存—确认扣减”的业务方案用于走查。具体一致性、重试、幂等和补偿机制需在技术设计中确认，产品图至少应明确异常归谁处理。若画图时发现冻结失败后仍能进入发货，说明缺少条件判断，不是少画一个箭头那么简单。

用正常、失败和变更三种问题复核

1. 正常兑换：从会员选择商品开始，沿着有标签的连线走到订单结果，确认每一步都有负责模块。
2. 失败兑换：分别假设积分不足、库存不足、通知失败，检查是否有结果解释、资源释放和人工处理入口。
3. 范围变更：若下一版加入“积分加现金”，圈出受影响的订单、支付和退款能力，再决定是否另开细节视图。

最后给图加上范围、版本和日期。通过分组表达包含关系，通过带标签的箭头表达依赖；只保留评审需要的连线，避免把每个模块都互相连接成网。

5.  产品架构图用什么软件画

（1）boardmix

Boardmix博思白板适合把需求材料、模块图和评审意见放在同一画布上讨论。可以用图形、分组和连接线表达产品层次，也可以从社区模板开始，按自己的角色、业务边界和模块职责逐项修改。模板提供的是起点，不能替你决定哪些能力属于本次产品。

当产品、研发和运营对一个模块的职责有分歧时，把不同意见留在对应区域，逐项确认“谁维护、谁调用、失败由谁处理”。这样讨论与图中的对象对应，避免评审后只剩一张没有决策依据的图片。

（2）Microsoft Visio

Microsoft Visio适合已有Microsoft绘图流程、需要规范图形与文档协作的团队。它有桌面与网页版，不能概括为“只能在Windows使用”。Microsoft官方的网页版说明列出了浏览器中的查看、编辑与分享能力；具体图形、数据连接和高级功能需要按所用版本与许可证确认。

（3）Lucidchart

Lucidchart是浏览器中的图表协作工具，适合跨团队共同维护流程和架构关系。其业务分析方案强调用现状与目标流程表达业务需求。需要特定集成或管理能力时，应比较所选套餐，不把“与所有工具无缝衔接”当作通用承诺。

6.  产品架构图模板分享

下面三类模板各有侧重点。挑选时先看它的模块和关系是否接近当前任务，再看视觉风格；已有模板越复杂，越要确认哪些层级与自己无关。不要因为模板里有某个模块，就自动把它加入产品范围。

（1）产品架构图模板

这张客户关系管理模板按销售管理、财务管理、公海管理和基础服务组织能力，适合练习模块分层。先区分线索、客户和成单，再检查合同、回款等信息由哪个模块维护；不要把所有“增删改查”都平铺在同一级。

产品架构图制作教程模板

（2）互联网产品架构图模板

这张互联网产品模板包括派工、订单、营销和支付等业务服务，适合比较不同模块的职责。图中把订单状态与订单操作分开，复用时要注意两者的区别：“已完成”是状态，“取消订单”是动作；若想表达状态转换规则，应另补状态图。

互联网产品架构图模板

（3）会员系统产品架构图模板

会员系统模板同时展示用户端、管理后台和数据等层次。做会员产品评审时，可先提取积分商城、互动中心、个人中心、用户管理等业务模块；图中的HTML、CSS和请求方式属于技术视角，不需要照搬到面向业务方的产品总览。

会员系统产品架构图模板

一张可用的产品架构图，应让读者找得到任务入口、说得清模块职责、沿关系找到异常归属。现在可以进入Boardmix工作台，用会员积分商城的职责表搭出第一版，再带着“库存不足”和“取消兑换”两种情况与团队走查。先把边界和关系画对，再处理配色与排版。