FRAME 38 / 制订策略

架构图

Business / System Architecture Diagram

把系统、业务或方案的组成部分和关系可视化。

制订策略信息共享

什么时候用

架构图适合说明复杂结构、业务系统、服务流程或组织协作。

需要准备

组件、关系和边界

你会得到

结构图、依赖清单、沟通材料。

先理解，再动手

架构图适合说明复杂结构、业务系统、服务流程或组织协作。它帮助团队看清元素之间的连接、依赖和责任边界。

使用步骤

01
确定要表达的系统范围
02
列出主要组成元素
03
用连接关系表示信息、价值、任务或责任流动
04
检查是否存在缺口、重复或关键依赖

使用时，留意这一点

不要为了完整而堆元素，图应服务于说明目的。

把方法看清楚

架构图结构示意 · 已填入虚构案例

使用者层

负责人上传；客户反馈；客服处理异常

产品层

项目空间 → 版本对照 → 批注确认

支撑层

权限校验、文件存储、通知投递

关键信息流

发布版本 → 发送链接 → 收集意见 → 确认结论

从一份空白提纲开始

复制到你的文档，填入真实的业务事实与判断。

查看空白提纲

架构图 · 空白提纲

工作问题：
期望结果：

1. 使用者层：

2. 产品层：

3. 支撑层：

4. 关键信息流：

检查清单
□ 图中元素和边界清楚。
□ 连接关系有明确含义。
□ 读者能快速理解整体结构和关键依赖。

BizThinkFrame · https://bizthinkframe.com/frameworks/architecture-diagram

跟着案例走一遍

虚构教学案例

WORKED EXAMPLE

解释审稿功能如何协同

组织、人物、数据和结果均为虚构，仅用于说明方法。

背景与问题

云桥要向客服与研发说明新的审稿系统结构。

不同团队把页面、服务和角色混在同一层讨论。

手头有哪些材料

参与者包括项目负责人、外部客户与客服
模块包括项目、版本、批注、通知与权限

如何使用这个框架

先明确图用于跨团队沟通，而非完整技术设计。
按使用者、产品模块和支撑能力分层，避免同层混放。
标出外部客户无需账号但仍需受控访问的依赖关系。

得到的结果

一张能说明角色、模块和信息流的结构图。

下一步行动

请客服按图演示一次异常反馈，补齐遗漏的处理环节。

检查你的思考

再问自己几个问题

这个系统由哪些关键部分组成？
哪些部分之间存在强依赖？
是否有职责不清或信息断点？

完成前的检查清单

图中元素和边界清楚。
连接关系有明确含义。
读者能快速理解整体结构和关键依赖。