4.2 KiB
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模块新增：CoachPerformancedomain、CoachPerformanceHandler、CoachPerformanceDaomanage-app的SystemRouter中新增 2 条路由
前端变更
StatisticsDashboard.vue新增"教练业绩"Tabstatistics.api.ts新增 API 接口类型- 可选：教练端新增个人业绩页面（通过路由守卫区分角色）
数据库
- 无新增表。完全基于现有表（
group_course、group_course_booking、coach_violation、sys_user）
备选方案记录
方案 A：基于签到表改造（已拒绝）
改造 sign_in_record 添加 coach_id 字段，使签到直接关联教练。
- 优点：数据更准确（签到是真实到店行为）
- 缺点：需要改表、改签到流程、影响面大；签到不等于上团课
方案 B：新建独立模块（已拒绝）
新建 gym-coach-performance 独立 Maven 模块。
- 优点：职责隔离清晰
- 缺点：模块碎片化，增加编译和依赖管理成本