架构图

架构图模板可以让团队快速得到分区、连接和视觉层级，但不能替团队决定系统边界。面对同一个系统，业务负责人、开发、运维和安全人员需要的图并不相同。模板选择的第一步不是挑样式，而是确定视角。

一、怎样选择架构图模板？先回答三个问题

1. 谁看：业务、产品、研发、运维、安全还是客户。
2. 做什么决定：确认范围、划分组件、选择技术、评审数据，还是规划部署。
3. 需要多细：系统级、应用级、组件级还是部署节点级。

如果无法回答这三个问题，建议先使用系统上下文模板梳理边界，不要直接进入技术分层或微服务模板。

二、六类架构图模板的选择矩阵

C4 Model用不同缩放层级向不同读者讲述不同故事。模板也应遵循同一原则：一张图只承担一个主要视角。

三、系统上下文图模板：先确定边界

系统上下文模板通常包含目标系统、用户/角色和外部系统。它的任务是让所有人先对范围达成一致，而不是解释内部技术实现。

• 把目标系统放在中心并写明核心职责。
• 外部角色和系统放在边界之外。
• 连接线用业务动作描述，例如“提交订单”“获取支付结果”。
• 明确排除项，避免评审过程中不断扩展范围。

当团队对“系统到底包含什么”仍有分歧时，这是优先级最高的模板。

四、系统与应用架构图模板：表达组件协作

系统/应用架构模板适合展示Web应用、移动端、后台服务、数据库、缓存、消息系统和外部接口。修改时应把通用方块替换为真实组件，并为每个组件写一句职责。

这里最常见的错误是把产品名称当成架构说明。图标可以帮助识别，但连接线上的动作、协议、数据或事件才真正支撑评审。

五、技术架构图模板：按职责分层而不是按流行词堆叠

技术架构模板常采用接入层、应用层、领域/服务层、数据层和基础设施层。分层应表达职责和依赖方向，而不是把“中台、微服务、AI、大数据”堆成若干彩色区域。

• 同层组件应具有相近抽象级别。
• 跨层调用要有明确原因，避免任意穿透。
• 公共能力应说明服务对象和治理方式。
• 技术选型旁保留关键约束或决策依据。

六、数据架构图模板：同时画出数据所有权和流向

数据架构图不只是数据库清单。模板应能够表达数据来源、采集/接入、处理、存储、服务和消费端，并说明敏感数据、权限和保留策略。

推荐把“谁拥有数据”与“数据流向哪里”同时画出来。只有流向没有所有权，问题发生时难以定位责任；只有存储没有流向，也无法判断链路和合规风险。

需要进一步细化时，可查看数据架构图定义与类型和数据架构图绘制步骤。

七、部署架构图模板：把环境、节点和故障域画清楚

部署架构模板面向运维、安全和研发，重点是环境、区域、网络、计算节点、数据节点、负载入口和外部依赖。它应能够回答组件运行在哪里、如何扩缩容、故障发生时如何切换。

• 区分开发、测试和生产环境。
• 标记地域、可用区、网络区或信任边界。
• 显示关键冗余关系和单点。
• 把监控、日志、备份和恢复入口纳入评审。

八、微服务架构图模板：从服务边界开始

微服务模板应围绕领域或业务能力划分服务，并显示网关、同步调用、异步事件、数据库归属与外部系统。不要从“需要多少个服务”开始，而要从“哪些能力需要独立演进”开始。

每个服务独立拥有数据并不意味着所有场景都必须一库一服务；模板应记录真实约束，而不是把某种模式当成绝对规则。可结合微服务架构图绘制指南继续细化。

九、业务与产品架构图模板：把能力和实现分开

业务架构模板用于表达业务能力、价值流、组织或流程；产品架构模板用于表达模块、层级、依赖和产品族。二者可以与技术图建立映射，但不应直接被技术组件淹没。

一种实用做法是给业务能力、产品模块和技术组件使用相同编号，在不同图中保持对应关系。这样既保持视角清晰，也能追踪某个业务变化会影响哪些产品和技术部分。

十、怎样用AI把模板变成真实架构图？

AI适合把需求整理为组件和关系，再填入模板骨架。建议流程如下：

1. 选择模板视角并说明读者。
2. 输入系统范围、参与者、组件、数据流和约束。
3. 让AI先输出缺失信息，而不是立即补全。
4. 生成初稿后在Boardmix中调整分组、关系和图例。
5. 用正常、异常和变化场景走查。

具体提示词和校验清单见AI生成系统架构图教程。AI可以帮助填充模板，但不应替团队决定安全、可靠性、成本和合规权衡。

十一、模板修改与质量检查清单

1. 标题是否说明视角、系统和适用版本。
2. 主要读者与要支持的决策是否明确。
3. 边界、分组和抽象层级是否一致。
4. 每个组件是否写明职责，而不只是产品名。
5. 连接线是否包含方向和语义。
6. 数据所有权、信任边界和故障路径是否可见。
7. 图例、术语、负责人和最后核验日期是否完整。

模板完成的标志不是所有占位符都被替换，而是团队能够通过它发现问题并做出决定。

十二、架构图模板常见问题

能否直接套用互联网大厂架构图？

不建议。参考架构适合学习模式和组件关系，但组织能力、规模、成本和约束不同。应只借鉴结构，再按真实需求重新验证。

模板里的图标必须全部保留吗？

不需要。删除与当前决策无关的元素通常比继续添加更重要，避免为了显得完整而制造错误信息。

应该先选模板还是先列组件？

先确定读者、决策和视角，再列关键组件，最后选择匹配的模板。只按外观选模板容易把内容带向错误层级。

模板更新后要保留旧版本吗？

重大架构决策和发布版本建议保留快照，并记录变更原因；一般布局调整可使用历史版本追踪。