系统架构图
系统由哪些模块组成面向方案沟通，先画业务模块和外部系统。不要在一张概览里同时堆满主机地址、表字段和接口参数。
选对图，再开始
先确定这张架构图要回答什么
架构图用组件、分层和连接关系描述系统的组织方式。它应说明系统由什么组成、各部分怎样协作、边界在哪里。画之前先确定读者和视角：业务负责人需要能力全貌，研发需要接口依赖，运维需要部署和网络信息。
技术架构图
服务怎样实现与部署面向研发与运维，补充技术组件、协议、运行环境及依赖。逻辑关系和部署位置不一致时，拆成两个视图。
数据架构图
数据从哪里来、到哪里去面向数据治理，描述数据源、处理环节、存储与使用方。需要表结构和主外键时，再使用 ER 图展开。
一个可复用的工作示例
订单系统：一张图讲清边界与依赖
以下是简化的逻辑架构示例：客户端经接口层提交订单，订单服务调用库存服务并访问订单库，支付交给外部支付平台。箭头表示调用或读写依赖，不表示业务步骤的时间顺序。
入口与职责
客户端不直接访问数据库；接口层接收请求，订单服务处理订单相关业务，库存服务负责库存能力。
数据边界
订单服务访问订单库，库存服务访问库存库。图中拆库用于解释归属，不意味着所有系统都必须采用微服务或独立数据库。
外部依赖
支付平台放在系统边界之外。同步请求、异步回调和失败补偿需要另补时序或流程说明，不能只靠一条线推断。
这是用于沟通的逻辑视图，不是生产部署建议。实际方案还需评审鉴权、幂等、库存一致性、支付回调及故障恢复。
从资料到可讨论的图
架构图怎么画？按这四步开始
选定读者与范围
在图上写明系统名称、版本和本图目的。先决定展示现状还是目标方案，只画本次要讨论的边界。
分层并命名组件
先列入口、业务能力、数据及外部系统。每个组件写清职责，保持同一层的抽象粒度一致。
用连线说明关系
给关键连线标注“调用”“读写”“事件”等语义；标出方向及外部边界。不同线型需要图例，不能让读者猜。
检查后形成评审结论
沿一条真实请求核对依赖，检查遗漏组件和不合理跨层访问。将争议、决策和待验证事项放在图旁，并标明日期与负责人。
不止画出来，还要一起讲清楚
架构图与评审资料，放在同一块白板
保留一张全局视图，再按需要展开子系统。Boardmix 的画布可将架构、文档、方案说明和评论组织在一起，适合远程评审和持续维护。
从概要逐步展开
用区域组织系统、子系统与局部细节，先讲全貌，再深入某一条调用链。
让取舍有上下文
在方案旁补上限制条件、接口说明或决策记录，区分“已确定”与“待验证”。
交付前检查可读性
统一组件命名、线型和颜色。分享前检查访问权限；导出后确认图例与关键标注仍可辨认。
AI 辅助，人工确认
用 AI 整理候选组件，用评审确认设计
可以先用 AI 助手整理需求、组件清单和待确认问题，再到画布中组织分层与关系。不要把生成的初稿当作已验证架构；技术选型、接口能力、容量及安全边界需要实际材料支持。
阅读 AI 辅助架构图方法 →社区作品 · 可查看完整模板
从社区模板开始制作架构图
先看预览，找到与任务接近的结构，再打开模板替换成自己的材料。
前后端分层
系统架构图之前后端分离
参考前端、服务和数据层的边界，按实际技术栈调整。
查看社区模板↗
多租户系统
多租户系统架构设计图
梳理共享能力与租户边界，记录需要评审的隔离方案。
查看社区模板↗
部署与接入
系统网关部署架构图
对照网关和服务连接方式，补充环境与网络约束。
查看社区模板↗在社区寻找更多系统架构图案例，查看完整作品与使用条件。
浏览更多系统架构图模板架构图常见问题
架构图和流程图有什么区别？
架构图强调“由什么构成、怎样依赖”，流程图强调“先做什么、条件满足后去哪里”。架构图中的箭头要标明关系，不能默认理解为时间顺序；需要解释完整业务过程时可配一张流程图。
系统架构图与技术架构图要放在一起吗？
可以在同一画布中分区呈现，但最好保留不同视图。系统概览说明模块与边界，技术视图补充实现与部署。保持组件命名一致，并用链接或标注建立对应关系。
能用组织架构图表达系统架构吗？
不建议混用。组织架构图表现部门、岗位和汇报关系，系统架构图表现软件组件及依赖。系统负责人可以作为组件的附加信息，但不能把管理层级当成系统分层。
支持用模板和 AI 开始绘制吗？
可从架构图模板参考布局，结合图形和连接线调整。AI 适合协助整理需求、组件和说明；是否能生成特定结构应以当前工具能力为准，初稿必须由熟悉系统的人校对。
如何分享给团队或放进方案文档？
持续讨论时分享画布并设置适合的权限；归档或汇报时，在编辑器中选择可用导出方式。导出前先看完整图与局部细节，检查图例、方向、字体和背景；具体格式与权益以当前界面为准。
方法与实践
继续完善架构图的边界与关系
从系统分层、技术组件到 AI 辅助初稿，找到本次评审需要的方法。
粤公网安备44030502008643