外卖系统——第一次迭代

外卖系统 - 外卖订单系统需求分析说明书

1. 文档背景与目标
   本项目为“外卖系统”的核心子模块——外卖订单系统，目标是通过敏捷需求分析方法，快速迭代实现订单全生命周期管理功能，支持高并发场景下的稳定运行，提升用户体验与商家运营效率。

产品愿景
目标用户： 忙碌的消费者、希望提升效率的餐饮商家。

核心痛点：
用户： 等待时间长、订单状态不透明、选择困难。
商家： 高峰期订单管理混乱、出餐效率低、营销难。
我们的解决方案： 一个集智能调度、实时追踪、高效管理于一体的下一代外卖平台。
核心价值：
用户： 最快30分钟送达（比平均快40%），全程可视化追踪，个性化推荐。
商家： 智能订单管理提升出餐速度30%，精准营销工具增加销量。
差异化优势： 业内领先的智能调度算法，深度融合三方需求，打造真正高效、透明、共赢的外卖生态。
愿景： 成为最值得信赖的即时配送平台，让美味无需等待，让经营更轻松，让配送更高效。

2. 需求范围
   2.1 核心功能模块

• 用户下单与支付
• 订单状态流转与实时通知
• 订单查询与评价
• 商家接单与骑手配送管理
• 数据统计与运营分析

2.2 排除范围

• 用户账户注册/登录（由用户中心模块负责）
• 菜品库存管理（由商品管理模块负责）

项目亮点

高并发与高可用架构：
支持每秒500+订单处理，采用分布式微服务架构，确保系统稳定性和弹性扩展能力。

智能动态优化：
基于AI算法的骑手路径规划与订单分配，提升配送效率10%以上。

全链路实时通知：
通过WebSocket+短信双通道推送，确保用户、商家、骑手三方信息同步零延迟。

数据驱动的运营支持：
多维度数据看板帮助商家分析经营趋势，快速调整营销策略。

极致用户体验：
智能优惠叠加、预计送达时间展示、一键异常上报等功能，显著提升用户满意度。

3.用户角色与用户故事
消费者场景：

用户故事1：作为消费者，我希望在订单确认页看到预计送达时间，以便安排用餐计划。
用户故事2：作为消费者，我希望在支付时自动叠加平台优惠券和商家折扣，减少手动操作。

商家场景：

用户故事1：作为商家，我希望系统自动推荐热门商品置顶，提升销量。
用户故事2：作为商家，我希望在订单高峰时段接收智能接单建议（如批量接单），减少人工操作压力。

骑手场景：

用户故事1：作为骑手，我希望通过地图导航实时避开拥堵路段，确保准时送达。
用户故事2：作为骑手，我希望一键上报异常情况（如交通堵塞、客户联系不上），同步通知消费者和商家。

角色 核心需求 优先级
消费者 快速下单、实时跟踪订单、支付便捷、评价订单 高
商家 高效处理订单、管理配送、查看订单统计 高
系统管理员 监控订单异常、管理基础数据（如配送费规则） 低

4. 功能需求清单
   4.1 迭代1：核心订单流程
   4.1.1 用户下单

• 用户故事：作为消费者，我希望通过购物车选择商品并生成订单，以便完成购买。
• 验收标准：

1. 支持商品多选、数量修改、优惠券抵扣。
   2. 订单生成后自动跳转至支付页面。
   3. 订单超时未支付自动取消（默认15分钟）。

4.1.2 订单支付
-用户故事：作为消费者，我可以通过多种支付方式（微信/支付宝）完成付款。

• 验收标准：
  1. 支付成功/失败实时反馈至用户与商家。
  2. 支持支付状态异常时的自动重试机制。

4.1.3 订单状态流转

• 用户故事：作为商家，我需要实时接收新订单并更新状态（接单/拒单/出餐完成）。
• 验收标准：
  1. 状态变更后实时推送至消费者。
  2. 商家超时未接单自动取消订单。

4.2 迭代2：增值功能与优化
4.2.1 订单查询与评价

• 用户故事：作为消费者，我可以在历史订单中查看详情并对已完成订单进行评分和评论。
• 验收标准：
  1.评价支持图片上传和匿名功能。

2. 商家端可回复评价，系统自动过滤敏感词。

4.2.2 数据统计看板

• 用户故事：作为商家，我需要查看每日订单量、营收趋势和热门商品排行。
• 验收标准：
  1. 支持按时间、商品类别等多维度筛选。
  2. 数据可视化（折线图、柱状图）。

---

5. 非功能需求
   5.1 性能要求

• 支持每秒500+订单并发，响应时间≤2秒。
• 支付接口99.9%高可用性。

5.2 安全性

• 敏感数据（如支付信息）加密传输（HTTPS+AES）。
• 防止重复提交订单（前端防抖+后端幂等性校验）。

5.3 可扩展性

• 模块化设计，支持未来扩展预约订单、团购订单等场景。

6. 外部接口依赖
   -支付系统：对接微信支付、支付宝API。

• 地图服务：集成高德/腾讯地图API实现路径规划。
• 消息推送：使用短信网关（如阿里云SMS）及WebSocket实时通知。

7. 风险与应对
   风险 应对措施
   支付延迟风险 设计异步支付状态轮询机制

8. 验收与交付计划

9. 迭代1交付：完成核心下单、支付、状态流转功能（4周）。

10. 迭代2交付：上线评价系统与数据看板（3周）。

11. 迭代3（可选）：智能订单分配算法优化（2周）。

9.UML核心类图

架构分层设计（MVC 思想落地）

用 「前后端分离 + 分层架构」 ，拆分 3 大核心层：
A[前端页面] --> B(Controller 控制层)
B --> C(Service 业务层)
C --> D(Dao 数据访问层)
D --> E[MySQL 数据库]
B --> F[Redis 缓存（可选）]

• 控制层（Controller）：
  接收前端请求（如  /order/submit ），校验参数，调用 Service 处理业务。
  示例代码（Spring Boot）：

@PostMapping("/order/submit")
public Result save(@RequestBody DishDTO dishDTO) {
log.info("新增菜品{}",dishDTO);
dishService.saveWithFlavor(dishDTO);
//清理缓存数据
String key="dish_"+dishDTO.getCategoryId();
cleanCache(key);
return Result.success();

• 业务层（Service）：
  实现核心逻辑（如下单校验库存、计算价格、生成订单），调用 Dao 操作数据库。
  示例：OrderService包含 submit()方法，串联「查菜品 → 扣库存 → 写订单」流程。

public void saveWithFlavor(DishDTO dishDTO) {

Dish dish = new Dish();
BeanUtils.copyProperties(dishDTO, dish);

//像菜品表插入1条数据
dishMapper.insert(dish);
//获取insert语句生成的主键值
Long dishId = dish.getId();

List<DishFlavor> flavors = dishDTO.getFlavors();
if(flavors != null && flavors.size() > 0) {
    flavors.forEach(dishFlavor -> {
        dishFlavor.setDishId(dishId);
    });
    //向口味表插入n条数据
    dishFlavorMapper.insertBatch(flavors);

}

}

• 数据访问层（Dao）：
  通过 MyBatis Plus 操作数据库，定义 Mapper 接口 + XML（或注解）。
  示例：

insert into dish_flavor(dish_id,name,value)VALUES (#{df.dishId},#{df.name},#{df.value}) }  

3. 核心流程时序图（用户下单示例）

用 时序图 说清模块交互（简化版）：

participant 顾客端 as 顾客（前端）
participant 控制层 as Controller
participant 业务层 as Service
participant 数据层 as Dao
participant 数据库 as MySQL

顾客端->>控制层: 提交订单（含菜品ID、地址）
控制层->>业务层: 调用 orderService.submit()
业务层->>数据层: 查菜品库存（Dao）
数据层->>数据库: SELECT stock FROM dish WHERE id=?
数据库-->>数据层: 返回库存
业务层->>数据层: 扣减库存（UPDATE dish...）
业务层->>数据层: 新增订单（INSERT INTO orders...）
数据层->>数据库: 执行 SQL
数据库-->>数据层: 操作结果
业务层-->>控制层: 返回订单ID
控制层-->>顾客端: 下单成功（含订单ID）