跳转至

3.1 明确方案：设计目标、约束与技术选型

先明确“为什么这样设计”，再决定“用什么技术实现”

技术选型不是框架点名

“前端用 Vue，后端用 Spring Boot，数据库用 MySQL”还不算完整的技术选型。你还需要说明：这些技术是否适合项目需求，团队是否能够掌握，课程时间内能否完成，开发和部署环境是否支持。

本节不追求使用最新、最复杂的技术，而是为项目选出一套做得出来、能够验证、便于解释的实现方案。

本节学习目标

根据《项目选题立项书》和《需求分析说明书》，明确系统设计目标、项目约束和技术方案，记录关键选择及其理由，为后续架构、原型、数据库和接口设计建立统一依据。

返回第三篇导读 进入下一节：设计架构

🎯 本节完成后，你要交付

成果 要求
设计依据清单 写清设计所依据的需求、范围和验收条件
设计目标与约束 明确项目优先保证什么、受到哪些条件限制
技术选型表 列出前端、后端、数据库及开发工具，并说明选择理由
关键决策记录 对重要选择记录备选方案、决定和影响

本节暂时不需要画完整架构图，也不需要创建项目代码。先把方案定稳，后面的设计才不会各说各话。

📄 第一步：确认设计依据

系统设计不能脱离需求自由发挥。开始前，先准备并检查以下材料：

设计依据 需要重点读取的内容 对设计的影响
《项目选题立项书》 项目目标、建设范围、进度和风险 决定系统做到什么程度
《需求分析说明书》 用户角色、功能、流程、规则和验收条件 决定系统需要支持哪些能力
调研与原始记录 用户反馈、同类产品和实际场景 帮助判断设计是否符合真实使用方式
课程与运行环境 开发周期、已有基础、服务器和数据库条件 限制技术复杂度和部署方式

建立需求到设计的对应关系

从需求文档中找出会直接影响设计的内容，不必重复抄写整份需求。例如“校园活动报名系统”可以整理为：

需求或条件 对设计提出的要求
学生和管理员使用同一系统 需要区分角色、菜单和操作权限
学生可以查看并报名活动 需要活动浏览、活动详情和报名流程
活动有人数上限 报名时需要校验名额，避免超额报名
管理员需要查看报名统计 需要保存报名数据并提供统计查询
项目需要在课程结束前上线 技术方案应便于开发、测试和部署

需求还没有确认，不要急着做设计

如果核心角色、业务流程或验收条件仍然含糊，应先返回第二篇完善《需求分析说明书》。系统设计可以细化实现方式，但不能替需求文档擅自增加功能。

🧭 第二步：确定系统设计目标

设计目标说明系统在实现时优先保证什么。目标应来自项目需求，并且可以通过后续设计、测试或演示进行检查。

常见设计目标

目标 要回答的问题 适合课程项目的表达示例
功能完整 核心业务能否形成闭环？ 学生能够完成“查看活动—报名—查看报名结果”全过程
使用清楚 用户能否顺利找到并完成操作？ 核心操作入口明确，失败时给出可理解的提示
数据正确 业务数据和状态能否保持一致？ 报名成功后名额和报名记录同步更新
权限安全 不同角色能否只访问允许的功能和数据？ 普通学生不能进入活动管理功能
易于维护 代码职责是否清楚，后续是否方便修改？ 页面、业务逻辑和数据访问按职责划分
能够部署 项目能否在指定环境中稳定运行？ 系统能够部署到课程提供的 Linux 服务器

目标不宜写成“界面美观”“性能良好”“安全性高”这类无法判断的口号。可以改成更具体的表达：

1
2
3
4
5
不清楚：系统响应速度快。
较清楚：普通列表查询在课程演示数据规模下能够正常返回，页面无明显等待。

不清楚：系统安全性高。
较清楚：用户登录后才能访问个人数据，普通用户不能调用管理员接口。

课程项目优先保证核心业务闭环

如果时间有限，优先保证功能正确、数据一致、权限清楚和项目能够部署。微服务、高并发、复杂中间件不是大多数课程项目的必要目标。

🚧 第三步：识别项目约束

约束是设计方案必须面对的现实条件。忽略约束，方案即使看起来先进，也可能无法完成。

从 5 个方面检查约束

约束类型 需要确认的问题 示例
时间约束 剩余多少周？每周能投入多少时间？ 4 周内完成核心开发，不采用学习成本过高的框架
人员约束 个人还是团队？成员掌握哪些技术？ 两人组队，一人熟悉 Java，一人熟悉 Vue
技术约束 课程、模板或已有代码规定了什么？ 使用 JDK 17，复用课程提供的 Spring Boot 项目结构
环境约束 系统在哪里开发、运行和部署？ 开发机使用 Windows，最终部署到 Linux 服务器
数据与合规约束 是否涉及隐私、敏感数据或外部服务？ 不采集身份证号；第三方 API 密钥不能写入代码仓库

建议把约束写成“条件 + 影响”，而不只是列出名词：

1
2
3
4
5
条件：项目由 1 人在课程周期内完成。
影响：采用前后端分离的单体架构，不拆分微服务。

条件：部署服务器资源有限。
影响：减少非必要中间件，优先使用已有数据库和部署环境。

🛠️ 第四步：比较并选择技术方案

技术选择应按照“项目需要什么”来决定，而不是按照“哪个技术听起来更高级”来决定。

先确定选择标准

比较候选方案时，可以使用以下标准：

选择标准 判断问题
满足需求 能否支持项目的页面、业务、数据和权限需求？
学习成本 你或团队是否掌握？短时间内能否学会并解释？
开发效率 是否有成熟脚手架、组件、文档和调试工具？
项目兼容 是否与课程模板、已有代码和运行环境兼容？
部署难度 能否在目标服务器上安装、配置和运行？
风险可控 遇到问题时是否容易查找资料、定位和替换？

课程推荐技术路线

对于普通 Web 管理系统，可以优先采用课程推荐方案：

层次或用途 推荐选择 主要作用
前端 Vue 3 构建页面、组件和用户交互
后端 JDK 17、Spring Boot 3 提供接口，实现业务逻辑和权限控制
数据访问 MyBatis 完成数据库查询和数据持久化
数据库 MySQL 或 openGauss 保存用户、业务记录和系统配置
接口调试 Apifox 编写接口文档、发送请求和保存测试示例
版本管理 Git 记录开发过程，支持回退和协作
AI 编程工具 Trae 辅助分析、设计、编码、调试和检查
部署 Linux、Nginx 运行后端服务并发布前端资源

这是一条推荐路线，不是所有项目的唯一答案。如果已有模板、团队经验或项目需求更适合其他技术，可以选择其他方案，但必须说明理由和风险。

技术选型表示例

选型项 候选方案 最终选择 选择理由 风险与应对
前端框架 Vue 3、原生 HTML Vue 3 适合组件化页面，课程已有基础 不熟悉状态管理，先用简单组件通信
后端框架 Spring Boot、Servlet Spring Boot 3 能快速搭建 RESTful API，便于分层开发 配置较多，复用课程模板
数据库 MySQL、openGauss MySQL 8 团队熟悉，开发环境已安装 部署前检查版本与字符集
系统结构 单体、微服务 前后端分离的单体应用 项目规模较小，开发部署更简单 后续模块增加时保持清晰分层

技术栈不是越多越好

Redis、消息队列、Elasticsearch、Docker、微服务等技术只有在需求确实需要、团队能够掌握并且有时间验证时才加入。为了“显得高级”增加技术，会扩大故障范围和交付风险。

📝 第五步：记录关键设计决策

技术选型过程中，一些决定会影响后面的架构、数据和接口设计。建议用简短的决策记录保留“为什么这样选”。

每条记录包含以下内容即可：

1
2
3
4
5
6
7
### 决策：采用前后端分离的单体架构

- 背景：系统包含学生端和管理端，需要多个交互页面和统一接口。
- 备选：传统服务端页面、前后端分离单体、微服务。
- 决定：采用 Vue 3 + Spring Boot 的前后端分离单体架构。
- 理由：符合课程技术基础，开发和部署复杂度可控。
- 影响：下一节需要分别设计前端、后端模块及二者的接口关系。

重点记录会影响多个模块、需要团队共同遵守或以后可能被追问的决定。普通的小设置不需要全部写成决策记录。

🤖 第六步：用 AI 辅助比较方案

AI 适合帮助你补充候选方案、比较优缺点和检查遗漏，但最终选择必须结合自己的项目条件。

可以把真实项目材料提供给 Trae：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
请先阅读《项目选题立项书》和《需求分析说明书》，
不要修改文件，也不要直接替我决定技术方案。

请完成以下分析：
1. 从需求中提取会影响系统设计的功能、角色、业务规则和质量要求；
2. 识别时间、人员、技术、部署和数据方面的约束；
3. 根据“满足需求、学习成本、开发效率、环境兼容、部署难度、风险”
   比较可选技术方案；
4. 给出推荐方案、选择理由、主要风险和更简单的备选方案；
5. 标出需求文档中仍需人工确认的问题。

所有结论必须说明依据；没有材料支持的内容请标记为“待确认”。

收到建议后，至少检查：

  • AI 是否真的依据项目文档，而不是给出通用技术清单；
  • 推荐的每项技术是否解决了明确问题；
  • 自己是否能够安装、使用、调试并解释这些技术；
  • 方案是否能在课程时间和部署环境内完成；
  • 是否出现了需求之外的功能或不必要的中间件。

不要把 AI 的推荐直接当成最终决定

AI 不知道你的真实熟练程度、课程进度和服务器条件。任何会增加依赖、改变数据库或明显扩大项目范围的建议，都需要你和团队确认。

📋 本节成果模板

完成分析后，可以用下面的结构整理本节成果，并在后续写入《系统设计说明书》：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
## 设计方案与技术选型

### 1. 设计依据
- 项目目标：
- 核心用户与业务流程：
- 必须实现的功能：
- 明确不做的内容：

### 2. 设计目标
- 功能与业务目标：
- 数据与权限目标：
- 使用与部署目标：

### 3. 项目约束
- 时间与人员：
- 技术与已有基础：
- 开发和部署环境：
- 数据与外部服务：

### 4. 技术选型
| 选型项 | 候选方案 | 最终选择 | 选择理由 | 风险与应对 |
| --- | --- | --- | --- | --- |
| 前端 |  |  |  |  |
| 后端 |  |  |  |  |
| 数据访问 |  |  |  |  |
| 数据库 |  |  |  |  |
| 开发与测试工具 |  |  |  |  |
| 部署方案 |  |  |  |  |

### 5. 关键设计决策
- 决策一：
- 决策二：

### 6. 待确认问题
- 问题一：
- 问题二：

✅ 本节自查

  • 设计方案能够对应《需求分析说明书》中的核心需求；
  • 已明确系统优先保证的设计目标；
  • 已识别时间、人员、技术、环境和数据方面的约束；
  • 每项主要技术都有与项目相关的选择理由；
  • 没有为了展示复杂度而加入不必要的框架或中间件；
  • 技术版本与开发、部署环境基本兼容；
  • 关键决策记录了备选方案、决定、理由和影响；
  • 尚不明确的问题已标记为“待确认”，没有自行编造答案；
  • 团队成员或教师已经确认该方案在课程周期内可完成。

当你能够用 2 分钟说明“系统优先保证什么、受到哪些限制、为什么选择这些技术”，就可以进入下一节，把总体方案进一步拆成系统架构和功能模块。

📝 总结

  • 先看需求，再定方案：技术选择必须服务于真实功能、业务规则和验收目标；
  • 先承认约束，再控制复杂度：时间、能力和环境决定了什么方案能够真正落地；
  • 选合适的，不选最多的：课程项目优先采用熟悉、稳定、便于开发和部署的技术；
  • 记录选择理由：明确“为什么这样选”，后续设计、开发和答辩才有一致依据；
  • AI 帮助比较，人负责决定：建议可以由 AI 补充，最终方案必须经过人工确认。

返回第三篇导读 进入下一节：设计架构