45 lines
5.2 KiB
Markdown
45 lines
5.2 KiB
Markdown
# 课程学习-习题-批改ER与对象类数据流图实施计划
|
||
问题陈述
|
||
基于现有《AI智能学习系统功能清单》与现有架构图，在不纳入 AI 实现细节的前提下，先完成“课程学习、习题、批改”三条主链路的抽象建模，产出可直接指导后续代码与数据库落地的模块化 ER 图与对象类数据流图（每模块一个目录、两个 drawio 文件）。
|
||
## 当前状态（已核实）
|
||
* 现有 `docs/architecture/数据流图（多角色）.drawio (1-158)` 已定义 P1-P7 过程与 D1-D6 数据存储，但把 AI 处理作为主链路节点之一，需要按新范围裁剪为“无 AI 依赖的批改主链路”。
|
||
* 现有 `docs/architecture/系统架构与代码架构.drawio (1-260)` 已给出分层和目标服务域（如 homework-content、grading-orchestrator 等），但仓库当前可运行模块仍以骨架为主。
|
||
* 后端现有聚合模块为 `common/apis/ai-client/auth/upms/gateway/boot-dev`（`backend/pom.xml (13-21)`），尚未落地课程/习题/批改独立业务模块。
|
||
* 数据库当前已落地的核心表主要是组织权限与认证、AI占位：`init/pg/upms/10_create_upms_tables.sql (1-153)`、`init/pg/auth/10_create_auth_tables.sql (1-56)`、`init/pg/ai/10_create_ai_tables.sql (1-47)`；尚无课程、题库、作业、提交、批改结果等业务实体。
|
||
* `auth`/`upms` 服务当前仍以示例返回为主（`backend/auth/src/main/java/com/k12study/auth/service/AuthService.java (1-66)`、`backend/upms/src/main/java/com/k12study/upms/service/UpmsQueryService.java (1-111)`），说明本次需要先补齐领域建模图，再推进代码实现。
|
||
## 目标范围与输出目录
|
||
* 范围仅覆盖：课程学习、习题（题库/作业/提交）、批改（规则批改+教师复核+结果反馈）。
|
||
* 明确不纳入：AI 子系统实现细节（OCR/LLM/ASR/模型编排）。
|
||
* 统一输出根目录：`docs/architecture/modules/`
|
||
* 每模块目录固定包含：`er图.drawio`、`数据流图.drawio`
|
||
* 模块目录规划：
|
||
* `docs/architecture/modules/00-组织与权限上下文/`
|
||
* `docs/architecture/modules/01-课程学习/`
|
||
* `docs/architecture/modules/02-习题与作业/`
|
||
* `docs/architecture/modules/03-批改与反馈/`
|
||
## 方案设计（ER + 对象类数据流图）
|
||
* 00-组织与权限上下文（复用现有 upms/auth）
|
||
* ER 聚焦租户、部门、用户、角色、权限、登录态对业务域的外键约束与数据隔离键（`adcode/tenant_id/tenant_path/dept_id/dept_path`）。
|
||
* 数据流图仅保留“身份鉴权、租户路由、权限校验”对象类交互，作为其它模块前置边界。
|
||
* 01-课程学习
|
||
* ER 规划课程主数据与学习行为：课程、章节、课时、知识点、课程资源、标签、课程-标签关联、学习会话、学习进度。
|
||
* 数据流图采用“学生/教师/机构管理员 -> Boundary(前端/API) -> Control(课程编排/进度服务) -> Entity(课程与进度聚合)”表达。
|
||
* 02-习题与作业
|
||
* ER 规划题库与作业域：题目、题目版本、题目-知识点关联、试卷、试卷题目、作业、作业发布对象、作业提交、题目作答明细。
|
||
* 数据流图区分教师发布链路与学生作答链路，明确命令流（发布/提交）与查询流（拉题/看作业）。
|
||
* 03-批改与反馈
|
||
* ER 规划批改闭环：批改任务、批改规则、客观题判分、主观题复核、评分明细、错因标签、错题沉淀、复习任务。
|
||
* 数据流图体现“自动规则判分 + 教师复核”双通道，不依赖 AI；预留抽象接口节点（GradingEnginePort）用于未来替换实现。
|
||
## 采用的设计方法与原因
|
||
* DDD 限界上下文：将课程、习题作业、批改反馈分域，避免单一大模型导致职责耦合与演进困难。
|
||
* 聚合根与不变量建模：以“作业、提交、批改任务”为聚合根，保证状态转换与评分一致性在事务边界内成立。
|
||
* 状态机建模：对作业（草稿/已发布/已截止）与批改任务（待处理/处理中/待复核/已完成）建状态流，减少流程分支歧义。
|
||
* CQRS（读写分离）思路：发布、提交、批改等写操作与学情统计、作业列表等读模型分离，适配高并发查询场景。
|
||
* 事件驱动与Outbox预留：提交后触发批改、批改后触发错题沉淀/复习任务，降低模块同步耦合并提高可扩展性。
|
||
* 多租户路由键统一：所有核心业务实体强制带租户/组织路径字段，保持与现有 upms 路由策略一致。
|
||
## 实施阶段与验收标准
|
||
* 第一阶段：建立统一 drawio 模板（图例、命名规范、主键/外键/基数标注规范、同步/异步箭头规范）。
|
||
* 第二阶段：完成 4 个模块目录与 8 个 drawio 文件，先 ER 后对象类数据流图，确保跨模块实体引用一致。
|
||
* 第三阶段：做跨图一致性校验（实体命名、状态枚举、事件名、租户字段、API对象名），并补充“代码落地映射”注释（对应未来 backend 模块与 init/pg 子目录）。
|
||
* 验收标准：每个模块必须同时具备 ER 与对象类数据流图；ER 图必须标明主外键、基数、关键索引与租户字段；数据流图必须标明 Actor/Boundary/Control/Entity 与关键输入输出对象。
|