技术架构图实战：分层展示系统职责

技术架构图用来回答“系统被拆成哪些层，每一层承担什么责任”。它不是技术栈清单，也不是 Logo 展示页。论文里的架构图应该让读者看出入口在哪里、业务能力在哪里、数据和基础设施放在哪里，以及这些层为什么这样分。

很多学生把 Vue、Spring、MySQL、Redis 放在几块矩形里，就以为是架构图。问题是读者仍然不知道前端请求先到谁、业务服务之间怎么分工、数据库为什么不直接暴露给用户。好的架构图要把这些边界画出来。

这张图由哪些东西组成

本工具的技术架构图用文本描述层级。最外层必须是 lane，它通常表示一层或一个区域；group、row、column 用来组织内部结构；真正的叶子节点是 block 和 database。

组件	DSL 写法	适合表达什么
分层 lane	lane: 业务层	终端层、接入层、业务层、数据层等大边界
分组 group	group: 图表服务	同一层内的一组能力
行 row	row	横向排列多个节点
列 column	column	纵向组织多行能力
功能块 block	block: 导出服务	页面、服务、网关、中间件等普通节点
数据库 database	database: MySQL	数据库、缓存、时序库等数据节点
文字方向	`block: 搜索推荐	text=vertical`	让窄块竖排显示

一个最小例子如下：

@title 论文图表工作台技术架构图

lane: 表现层
  row
    block: Nuxt 前端

lane: 业务层
  row
    block: 图表解析服务
    block: 文档导出服务

lane: 数据层
  row
    database: PostgreSQL
    block: 文件存储

后端会要求顶层都是 lane；容器类节点必须有子元素；block 和 database 不能再包含子元素。这样可以避免图的层级写乱。

lane 要按责任分，不要按技术热闹程度分

一张毕业论文里的技术架构图，常见分层可以是表现层、接入层、业务层、数据层、基础设施层。不是每个系统都要五层，简单系统可以少一点，但每一层都要有理由。

例如前后端分离系统可以这样解释：表现层负责页面交互和图表脚本编辑；业务层负责解析、布局、导出和权限判断；数据层保存项目、图表文档和用户信息；基础设施层提供缓存、对象存储或消息队列。只写“使用 Nuxt、ASP.NET Core、PostgreSQL”不够，因为那只是技术选择，不是结构设计。

group 用来收束复杂度

如果业务层有很多服务，不要把所有 block 摊成一长排。可以用 group 把图表生成、项目管理、文档导出归到不同能力组里，再用 row 或 column 控制排布。这样读者先看见职责边界，再看组内细节。

也要克制：一个小系统硬拆十几个 group，会显得像为了复杂而复杂。论文评阅更看重能否说清楚“为什么这样拆”，而不是节点数量。

架构图不画箭头也要讲调用方向

当前技术架构图 DSL 主要表达分层和包含关系，不是调用链图。它不会像流程图那样用箭头描述每一次调用。因此正文里必须补一句调用方向：用户通过前端进入系统，前端调用 API 服务，业务服务读取数据库或调用导出组件。

如果你需要展示具体接口先后顺序，应另画时序图；如果要展示部署网络和端口，应画网络拓扑图。不要让一张架构图承担所有任务。

写进论文时怎么落笔

图题可以写成“图 3-1 系统技术架构图”。图后建议按层说明，不要逐个念框名：

系统采用前后端分离架构。表现层负责图表脚本编辑和导出交互，业务层负责脚本解析、布局计算与文档生成，数据层保存项目和图表文档。该划分降低了页面交互与文档生成逻辑之间的耦合。

这段文字能说明设计理由，比“系统架构如下图所示”有用得多。

定稿前检查

• 最外层是否都是清晰的分层或区域。
• block、database 是否只作为叶子节点使用。
• 每一层是否能在正文里讲出职责。
• 技术名是否服务于结构说明，而不是堆名词。
• 具体调用链是否交给时序图或流程图表达。