系统功能结构图怎么画？6步拆分模块与功能边界

系统功能结构图怎么画，先要回答“系统边界在哪里、有哪些功能、每个功能如何继续拆分”，再把这些内容按层级放入图中。以订单支付场景为例，可以把订单管理、支付处理、库存管理和消息通知列为一级功能，再分别展开创建订单、查询订单、发起支付、查询支付结果等子功能。功能结构图以“包含关系”为主；模块调用、数据流和异常处理可以作为补充说明，但不要混成同一层连线。需要使用 UML 表达组件或交互时，可进一步参考UML 图绘制工具的图形边界。

开始绘制前，先写三项基线：系统不负责什么、图要给谁看、最后要支持什么判断。架构评审关注模块边界和依赖，开发联调关注接口和数据流，运营说明则可能只需要功能层级；同一系统不必用一张图回答所有问题。

下面的支付系统分层架构图展示了清楚的模块分组方式。绘制功能结构图时可以借鉴这种分区和命名方法，但应先保留业务功能层，不把网关、数据库和部署设施直接当成同级业务功能。

1. 确定系统范围

先画一个只包含系统名称的外框，写清输入、输出、外部参与者和约束条件。支付系统的输入可以是订单号、金额和支付方式，输出是支付结果、状态事件和对账记录；第三方支付平台、银行或消息服务放在系统边界外。不要把“所有相关业务”都塞进边界，否则后续模块会不断膨胀。

再把范围拆成能独立说明责任的子系统，例如订单、支付、库存、通知和对账。若一个框里同时出现界面、数据库和业务规则，说明层级混杂，应先选择功能视图或组件视图，再继续拆分。

2. 确定子系统之间的关系

先检查父功能与子功能的包含关系，再单独标出跨模块依赖。比如“支付处理”可以包含发起支付、结果查询和退款；订单、支付、库存之间的接口关系另用附表记录，不和功能分解线混用。下面是一种订单支付方案的关系记录方式，其中库存扣减时机只是本方案的约定；预占库存、支付超时释放等规则应按实际业务补充，不能从图形位置推定。

系统功能结构图连接关系记录表

来源→目标	关系类型	需要标注的内容	异常问题
订单→支付	同步调用	订单号、金额、幂等键	重复提交如何处理
支付→订单	状态事件	成功、失败、待确认	回调丢失或重复
订单→库存	条件触发	仅在已支付后扣减	库存不足如何回滚

3. 绘制系统框

在画布上先绘制系统总框，再在内部放置一级子系统。总框表达范围，内部框表达职责；连接线不要穿过无关模块。支付系统可把订单和支付放在核心区域，把第三方平台和消息服务放在边界外，用不同线型区分内部调用和外部依赖。

4. 标识子系统

每个模块至少写名称、职责和主要输入/输出。名称使用团队已经约定的称呼，避免同一个模块在图中出现“支付中心”“收款服务”两个名字。层级较深时，先保持一张图只呈现两到三层；更细的接口字段可以放到下一张接口图或附表中。

5. 绘制子系统之间的联系

功能分解线从父功能连到子功能，连线不要穿过无关模块。若需要评审跨模块配合，可另画交互附图，并在线旁标注数据或事件名称：支付失败后订单如何处理、第三方回调超时如何核对，都应有明确归属。主图回答“有哪些功能”，附图回答“这些功能怎样协同”，避免为了补异常把功能结构图改成流程图。

如果连接线明显交叉，优先重新安排模块位置或拆分视图，不要靠增加颜色和线宽掩盖方向。涉及多人评审时，可在节点旁留下责任人和待确认问题，但不要将未验证的接口能力写成确定结论。

选择符号时先确定图中要表达的关系。Boardmix 图形库提供流程图、UML、BPMN 等分类；只打开本图需要的符号集，再统一模块、判断和边界形状。

6. 完善系统功能结构图

最后按读者的任务走读一次：架构评审者能否看出边界和关键依赖，开发者能否找到接口方向，测试人员能否找到成功和失败出口。补充图例、版本、适用环境和复核日期；如果某条关系只是待确认假设，使用待确认标记并写下负责人，而不是删除它。

需要参考结构时，可以在社区按架构图分类筛选模板，再替换成自己的系统模块。模板中的形状、边框和填充颜色可以按团队规范调整，但样式变化不能改变模块关系。系统功能图与 UML、数据流图的侧重点不同：需要类、属性和方法时使用类图，需要数据加工和存储时另画数据流图。

发布前的系统结构图检查清单

系统功能结构图发布前检查清单

检查项	通过标准
范围	系统边界、外部参与者和输入/输出都已写明
职责	每个模块有单一主要职责，名称前后一致
关系	连接方向、关系类型、数据或事件名称可复述
异常	失败、超时或回滚至少有一个明确出口
版本	图例、版本、适用范围和复核日期可追溯

完成后可以把画布链接分享给评审者，邀请他们在具体节点旁留下意见；需要交付文件时，根据当前页面和账号提供的入口选择图片或文件格式。想继续查看绘图知识，可前往Boardmix 绘图专题；准备好案例后，再打开 Boardmix绘制并持续维护。