新增e2e测试脚本,修复部分问题
This commit was merged in pull request #51.
This commit is contained in:
@@ -0,0 +1,98 @@
|
||||
# ADR-0001: 教练业绩统计功能设计
|
||||
|
||||
**日期**: 2026-07-22
|
||||
**状态**: 已决定
|
||||
**决策者**: 通过 grill-with-docs 追问明确
|
||||
|
||||
---
|
||||
|
||||
## 背景
|
||||
|
||||
需要在后台管理系统中为体育馆新增"教练业绩统计"功能。现有系统已有 `gym-dataCount` 模块提供全局统计(含教练违规统计 `CoachStatistics`),但缺少**按教练维度**的业绩数据(授课量、出勤率、满员率等正向指标)。
|
||||
|
||||
---
|
||||
|
||||
## 决策
|
||||
|
||||
### 1. 架构:扩展现有 gym-dataCount 模块
|
||||
|
||||
**选择**: 在 `gym-dataCount` 模块中新增 CoachPerformance 相关的 Handler + Service + DAO,而非新建独立模块。
|
||||
|
||||
**理由**:
|
||||
- `gym-dataCount` 模块已有成熟的统计架构(DatabaseClient + Reactive + Redis 缓存 + 时间范围推导)
|
||||
- 现有 `DataStatisticsDao` 已有教练相关的 SQL 聚合查询,可直接复用
|
||||
- 避免模块膨胀,将"统计"职责收敛在一个模块中
|
||||
- `manage-app` 已依赖 `gym-dataCount`,路由注册零成本
|
||||
|
||||
**替代方案被拒绝**: 新建 `gym-coach-performance` 独立模块。理由:功能规模不足以支撑独立模块,且会引入额外的模块间依赖管理成本。
|
||||
|
||||
### 2. 数据源:完全基于团课预约数据
|
||||
|
||||
**选择**: 业绩统计的"出席人次"和"出勤率"完全基于 `group_course_booking` 表(status='2'=已出席),而非 `sign_in_record` 签到表。
|
||||
|
||||
**理由**:
|
||||
- `sign_in_record` 表中没有 `coach_id` 字段,签到只关联会员(member_id),不关联教练
|
||||
- 学员→教练的唯一数据路径是:member → group_course_booking → group_course → coach_id
|
||||
- 改造签到表会增加数据库变更成本,且签到不等于上课(签到可能发生在任何时间)
|
||||
|
||||
**风险**: 如果未来签到记录需要关联教练(例如一对一的私教签到),需要重新评估此决策。
|
||||
|
||||
### 3. 授课量定义:仅计入已完成课程
|
||||
|
||||
**选择**: 只统计 `status IN (2, 6)` 的课程(已结束 + 自动结束)。
|
||||
|
||||
**拒绝的定义**:
|
||||
- 所有非取消课程:会包含教练缺席(status=5)的课程,不应算作业绩
|
||||
- 所有排课:会包含已取消的课程,不能反映真实工作量
|
||||
|
||||
### 4. 满员率:按出席人数计算
|
||||
|
||||
**选择**: 满员率 = 各课程(出席人数 / max_members)的平均值。
|
||||
|
||||
**拒绝的定义**: 按预约人数(current_members)计算。理由:预约了但没来的学员不能算"满员",出席人数更真实地反映了课程实际到场情况。
|
||||
|
||||
### 5. 综合评分权重:授课量 40% + 出勤率 30% + 满员率 30%
|
||||
|
||||
**选择**: 授课量占比最高,体现工作量;出勤率和满员率体现教学质量。
|
||||
|
||||
**归一化规则**: 授课量按所有教练中最大值归一化到 0-100。这样即使只有少数教练开课多,评分也能合理分布。
|
||||
|
||||
**拒绝的替代方案**:
|
||||
- 三指标等权重(33/33/34):弱化了工作量差异
|
||||
- 授课量 50%:过度强调数量而忽视质量
|
||||
|
||||
### 6. 不包含学员留存率
|
||||
|
||||
**选择**: 首版不计算学员留存率。
|
||||
|
||||
**理由**: 现有系统缺少"学员持续上课"的显式数据模型。要实现留存率需要定义"留存"的判定规则(如:连续两个月以上预约同一教练的课程),这会引入新的领域概念,增加首版复杂度。
|
||||
|
||||
---
|
||||
|
||||
## 影响
|
||||
|
||||
### 后端变更
|
||||
- `gym-dataCount` 模块新增:`CoachPerformance` domain、`CoachPerformanceHandler`、`CoachPerformanceDao`
|
||||
- `manage-app` 的 `SystemRouter` 中新增 2 条路由
|
||||
|
||||
### 前端变更
|
||||
- `StatisticsDashboard.vue` 新增"教练业绩"Tab
|
||||
- `statistics.api.ts` 新增 API 接口类型
|
||||
- 可选:教练端新增个人业绩页面(通过路由守卫区分角色)
|
||||
|
||||
### 数据库
|
||||
- 无新增表。完全基于现有表(`group_course`、`group_course_booking`、`coach_violation`、`sys_user`)
|
||||
|
||||
---
|
||||
|
||||
## 备选方案记录
|
||||
|
||||
### 方案 A:基于签到表改造(已拒绝)
|
||||
改造 `sign_in_record` 添加 `coach_id` 字段,使签到直接关联教练。
|
||||
- 优点:数据更准确(签到是真实到店行为)
|
||||
- 缺点:需要改表、改签到流程、影响面大;签到不等于上团课
|
||||
|
||||
### 方案 B:新建独立模块(已拒绝)
|
||||
新建 `gym-coach-performance` 独立 Maven 模块。
|
||||
- 优点:职责隔离清晰
|
||||
- 缺点:模块碎片化,增加编译和依赖管理成本
|
||||
Reference in New Issue
Block a user