GDUT外卖系统设计报告
团队名称：王炸
成员及分工：
一、需求改进 & 原型优化
1. **核心功能聚焦
| 原功能模块 |
优化方案 |
|
| 多角色系统（用户/商家/骑手） |
简化为用户+商家双角色（骑手功能由商家兼任） |
|
| 复杂支付流程 |
保留微信支付+模拟校园卡支付（降级方案） |
|
| 实时轨迹追踪 |
降级为订单状态推送（节省高德API成本） |
|
| 智能推荐系统 |
改为"热销榜"静态推荐 |
|
2. 用户痛点与解决方案 ：
- 典型场景：
"学生小陈在课间通过GDUT外卖预约12:00送餐至教学楼，避免食堂排队"
3. 功能四象限分析
高价值高紧迫：在线支付、订单状态通知
高价值低紧迫：菜品收藏、历史订单
低价值高紧迫：商家评分、投诉入口
低价值低紧迫：个性化头像、夜间模式
4. WBS调整（甘特图）
gantt
title GDUT外卖Alpha阶段计划
dateFormat YYYY-MM-DD
section 核心功能
用户认证 :2025-04-23, 5d
菜品管理 :2025-04-28, 7d
订单流程 :2025-05-05, 10d
section 质量保障
接口联调 :crit, 2025-05-12, 3d
压力测试 :2025-05-15, 2d
二、系统设计
1. 精简技术栈
| 层级 |
技术选型 |
降级方案 |
| 前端 |
Vue3 + Uni-app |
去除TypeScript改用ES6 |
| 后端 |
Spring Boot |
改用MyBatis替代MyBatis-Plus |
| 数据库 |
MySQL主从 |
单库+定时备份 |
| 部署 |
Docker集群 |
腾讯云轻量服务器单机部署 |
2. 核心数据库表（ER图关键部分）
erDiagram
USER ||--o{ ORDER : "1:N"
USER {
bigint id PK
varchar(20) student_id
varchar(50) dorm
}
ORDER ||--|{ ORDER_DETAIL : contains
ORDER {
bigint id PK
varchar(10) status
}
DISH {
bigint id PK
decimal price
varchar(10) canteen
}
3. 安全与性能优化
- 认证：JWT + 微信快捷登录
- 支付：微信支付沙箱环境（模拟校园卡支付走本地虚拟账户）
- 缓存：Redis仅缓存热门菜品（非必需可移除）
三、Alpha任务分配
1. Sprint Backlog
| 任务 |
时间 |
交付物 |
|
| 微信登录对接 |
8h |
可获取openid的API |
|
| 订单状态机实现 |
12h |
状态流转单元测试 |
|
| 食堂档口选择器 |
6h |
带地理筛选的Vue组件 |
|
2. 每日站会流程
09:00-09:15 站立会议
09:30 更新Leangoo看板任务状态
17:00 代码提交至GitHub主分支（强制）
四、测试计划
1. 分层测试策略
| 测试类型 |
工具 |
覆盖率目标 |
| 单元测试 |
JUnit |
核心模块60% |
| 接口测试 |
Postman |
100%关键API |
| UI测试 |
Cypress |
主流程覆盖 |
2. 典型测试用例
用例ID：PAY_001
- 场景：用户余额不足时支付
- 步骤：提交订单→选择校园卡支付→余额不足
- 预期：返回"余额不足"提示并保留订单30分钟
五、成本控制方案
| 项目 |
预算 |
实际方案 |
|
| 人力 |
2人月 |
1名全栈+1名测试 |
|
| 服务器 |
60元/年 |
腾讯云2核4G |
|
| 域名备案 |
免费 |
使用学校二级域名 |
|
六、风险应对
| 风险 |
应对措施 |
| 微信支付审核延迟 |
使用沙箱环境演示 |
| 高并发订单崩溃 |
限流降级（Alpha阶段不处理） |
| 菜品图片存储超支 |
压缩至<300KB/张 |
浙公网安备 33010602011771号