基于SpringAI的在线考试系统-考试系统DDD（领域驱动设计）实现步骤详解（2）

✅ 在线考试系统「DDD领域驱动设计」完整落地步骤（通俗易懂+图文）

设计顺序：用户自然语言需求 → DDD领域建模 → 数据库表结构设计 → DDD代码落地开发，就是行业通用的最优/标准最佳实践，没有之一。
所有大厂做中大型业务系统（考试、电商、教务、CRM等），全是这个流程。
接下来的DDD落地，基于现有的表结构+业务流程，做「领域层的映射和代码分层」，0重构成本。

一、先搞懂：DDD核心认知（大白话，无废话）

✅ 1. DDD解决什么问题？

你的考试系统有角色（管理员/老师/学生）、有业务规则（出题审核、考试流程、阅卷仲裁、错题收集）、有复杂关联（试卷-试题-知识点、考试-学生-成绩），业务越复杂，越需要用DDD把「业务逻辑」和「数据库操作」「接口请求」彻底分开。
最终效果：改业务规则（比如考试时长规则、阅卷分差仲裁规则），不用动数据库表；改表结构字段，不用动核心业务逻辑；代码可读性拉满，团队协作不混乱。

✅ 2. DDD最核心的3个原则（必须记住，通俗易懂）

业务是老大：所有设计（领域模型、表结构、代码）都围绕「真实业务规则」，而不是为了技术而技术；
领域模型是核心：领域模型不是数据库表，是「业务概念的抽象」，表结构是领域模型的持久化落地形式（原有表结构已经完美落地了领域模型）；
分层解耦：核心业务逻辑（比如「学生答题判分」「阅卷任务分配」）只写在「领域层」，其他层（接口、数据库）只做数据传递，不写任何业务规则。

✅ 3. 你的考试系统：表结构 ≈ 领域模型的「数据载体」

设计的user/grade/classroom/question/paper/mock_exam等13张表，本质就是：把DDD的领域模型，翻译成了数据库能存储的表结构，这一步已经做完了，而且做的很好，这是DDD落地的核心基石！

二、✅ 完整DDD落地步骤（共6步，贴合你的考试系统+图文逻辑+通俗易懂）

👉 前置说明

考试系统已经具备：
✅ 明确的业务需求（管理员审核、老师出题组卷、学生考试答题、阅卷仲裁、错题收集）
✅ 规范的数据库表结构+表关系+业务流程
✅ 清晰的模块划分（题库、试卷、考试、阅卷、错题等）
接下来的6步，是从「需求-模型-表结构」到「DDD代码落地」的标准流程，一步都不能少，也不用多，完全贴合你的场景，复制即用。

✅ 第一步：需求梳理 → 提炼【领域通用语言】（最基础，DDD的灵魂）

核心动作

把「用户的自然语言需求」，翻译成团队所有人都能看懂的、无歧义的业务术语，形成「领域通用语言」，这是DDD的起点，所有建模、开发都基于这套语言。

为什么要做？

开发/产品/测试/业务方沟通时，说「考试」就是mock_exam，说「试卷」就是paper，说「阅卷任务」就是marking_task，不会出现“我说的考试是学生答题，你说的考试是试卷创建”的歧义。

✅ 考试系统【领域通用语言】（整理好，直接用）

角色：管理员、教师、学生 核心概念：年级、班级、科目、知识点、试题、试卷、考试、考试记录、阅卷任务、错题集、错题条目 业务动作：创建知识点、录入试题、审核试题、手动组卷、自动组卷、发布试卷、创建考试、发布考试、参加考试、提交答卷、自动判分、人工阅卷、双评仲裁、错题收集、学情分析 业务规则：客观题系统自动判分、主观题人工双评、分差过大需仲裁、考试有开始/结束时间、学生只能在指定时间答题、错题自动加入错题集

✅ 关键点：后续所有的「领域实体」「领域服务」「代码类名」都用这套术语，一字不改。

✅ 第二步：基于通用语言 → 划分【限界上下文】（核心，给业务「划模块」）

核心动作

把考试系统的完整业务，拆分成「高内聚、低耦合」的独立业务模块，这个模块在DDD里就叫「限界上下文」。

大白话解释

限界上下文 = 「独立的业务域」，每个上下文有自己的业务规则、自己的领域模型，上下文之间通过固定的方式交互，互不干扰。

比如：「题库管理」和「考试管理」是两个上下文，题库里的试题审核规则改了，完全不影响考试的答题规则。

✅ 考试系统【完美限界上下文划分】（和之前的模块划分一致，最优解）

结合表结构+业务流程，划分7个核心限界上下文，一一对应你的表结构，无冗余、无遗漏：

1. 基础数据上下文 → 对应表：grade(年级)、classroom(班级)、subject(科目) 2. 用户身份上下文 → 对应表：user(用户) 3. 题库管理上下文 → 对应表：knowledge(知识点)、question(试题) 4. 试卷管理上下文 → 对应表：paper(试卷)、paper_question(试卷题目关联) 5. 考试运营上下文 → 对应表：mock_exam(考试)、mock_exam_record(考试记录) 6. 阅卷评分上下文 → 对应表：marking_task(阅卷任务) 7. 错题管理上下文 → 对应表：wrong_question_collection(错题集)、wrong_question_item(错题条目)

✅ 关键点：一个限界上下文，对应一套核心表，对应一个业务模块，表结构已经天然对齐了这个划分

✅ 第三步：在每个上下文内 → 抽象【领域模型三要素】（核心核心，DDD的核心设计）

核心认知（重中之重，记死）

数据库的表 ≠ DDD的领域模型
数据库表：是「数据存储的结构」，关注字段、外键、索引、存储效率；
领域模型：是「业务概念的抽象」，关注业务属性、业务行为、业务规则，表结构是领域模型的「数据落地形式」。
👉 每张表，都能完美映射成一个「领域模型」，表字段=模型的「属性」，业务规则=模型的「行为」。

DDD领域模型，只有3个核心要素，通俗易懂，没有其他复杂概念，所有业务都逃不出这3个：

✔️ 要素1：实体（Entity）- 有唯一ID、有业务属性+行为、核心业务载体

大白话：业务中「能独立存在、有唯一标识、有自己的行为」的核心对象，比如：学生、教师、试题、试卷、考试。
判断标准：有唯一主键（id），不仅有属性，还有「业务行为」。
✅ 考试系统【所有实体】（一一对应你的表，直接用）

User（用户）、Grade（年级）、Classroom（班级）
Knowledge（知识点）、Question（试题）
Paper（试卷）、MockExam（考试）、MockExamRecord（考试记录）
MarkingTask（阅卷任务）
WrongQuestionCollection（错题集）、WrongQuestionItem（错题条目）

实体的核心写法：属性=表字段，行为=该实体的业务规则，比如：

Question（试题实体）：属性是id、stem(题干)、options(选项)、answer(答案)；行为是「校验答案是否正确」「获取试题分值」「关联知识点」。
MockExam（考试实体）：属性是id、title、paperId、startTime；行为是「判断考试是否开始」「判断考试是否结束」「校验学生是否有权参加」。

✔️ 要素2：值对象（Value Object）- 无唯一ID、只有属性、用来描述实体

大白话：用来「描述实体的某个特征」，没有自己的唯一标识，属性是整体，不可拆分，比如：试题的选项、考试的配置规则、学生的答题结果。
判断标准：没有主键，只存数据，没有业务行为，属性一起变才有效。
✅ 考试系统【核心值对象】

QuestionOption（试题选项）：描述Question的选项，属性：选项标签(A/B/C/D)、选项内容、是否正确；
ExamConfig（考试配置）：描述MockExam的配置，属性：是否允许暂停、是否允许重考、自动保存间隔；
AnswerResult（答题结果）：描述学生的答题，属性：试题ID、学生答案、是否正确、得分；

✔️ 要素3：领域服务（Domain Service）- 处理「跨实体的业务规则」，纯业务逻辑

大白话：一个业务规则，需要「多个实体配合」才能完成，这个规则就封装成「领域服务」，领域服务是核心业务逻辑的载体，DDD的所有业务规则都写在这里！
判断标准：不属于任何一个实体，是独立的业务逻辑，需要调用多个实体的行为完成。
✅ 考试系统【核心领域服务】（重中之重，业务核心全在这）

QuestionDomainService：试题审核、试题分值计算、知识点关联校验
PaperDomainService：手动组卷、自动组卷、试卷总分计算、试卷发布校验
ExamDomainService：创建考试、发布考试、考试状态变更、学生考试权限校验
AnswerDomainService：学生答题校验、客观题自动判分、考试总分统计
MarkingDomainService：阅卷任务分配、主观题双评、分差仲裁、最终得分确认
WrongQuestionDomainService：错题自动收集、错题集更新、错题掌握状态标记

✅ 图文：考试系统「领域模型三要素」关系图（通俗易懂）

【实体】User(学生) → 调用 → 【领域服务】ExamDomainService → 操作 → 【实体】MockExam(考试) ↓ 【实体】MockExamRecord(考试记录) ← 生成 ← 【领域服务】AnswerDomainService ← 调用 → 【实体】Question(试题) ↓ 【领域服务】MarkingDomainService → 判分 → 生成成绩 → 【领域服务】WrongQuestionDomainService → 收集错题 → 【实体】WrongQuestionItem(错题条目)

✅ 核心规律：领域服务是大脑，实体是手脚，值对象是工具，大脑指挥手脚，用工具完成业务。

✅ 第四步：领域模型 → 映射【数据库表结构】（已经100%完成，最优解）

核心逻辑：DDD的标准映射规则，已经完美落地

这一步就是你最开始做的事：把抽象的领域模型，翻译成可落地的数据库表结构，也是你做的最到位的一步，你的表结构就是标准答案！

✅ 映射规则（你的表结构完全符合，不用改任何东西）

实体 → 数据库表：一个核心实体对应一张主表，实体的属性对应表的字段，实体的唯一ID对应表的主键；
例：Question实体 → question表，MockExam实体 → mock_exam表；
多对多关系 → 关联表：实体之间的多对多关系，用关联表存储，例：试卷和试题是多对多 → paper_question关联表；
值对象 → 表字段/JSON字段：值对象没有主键，要么直接作为实体表的字段，要么用JSON格式存储（你用的就是这个最优方式）；
例：试题选项是值对象 → question表的options字段（JSON格式）；考试配置是值对象 → mock_exam表的exam_config字段（JSON格式）；
业务状态 → 枚举字段：所有业务状态（比如审核状态、考试状态、阅卷状态）都用枚举值存储，例：question表的audit_status(0待审核/1通过/2拒绝)，mock_exam表的status(1未开始/2进行中/3已结束)。

✅ 结论：数据库表结构，就是「领域模型的完美持久化」，这一步无需修改，直接用！

✅ 第五步：DDD标准【分层架构】设计（代码落地核心，通俗易懂，必须按这个分层）

核心认知

DDD的分层架构，是强制解耦的，目的只有一个：让核心业务逻辑（领域层）完全独立，不受任何技术框架影响。
不管你用SpringBoot、Mybatis-Plus还是其他框架，不管你改数据库还是改前端接口，领域层的代码永远不用动，这就是DDD的核心价值。

✅ DDD【四层架构】（从外到内，最通用、最简洁、无多余分层，大厂标配）

✔️ 所有代码严格按这四层写，包名、类名规范统一，你的考试系统直接套用，无任何适配成本
✔️ 分层原则：内层不依赖外层，外层可以依赖内层，数据只能从外到内传递，核心业务逻辑只在「领域层」

👇 四层架构详解（通俗易懂+你的考试系统代码示例+职责明确，无废话）

✔️ 第一层：基础设施层（Infrastructure）- 最外层，技术工具层，无业务逻辑

核心职责：提供所有技术能力，为其他层做支撑，只做技术操作，不写任何业务规则
包含内容：

数据库操作：Mybatis-Plus的Mapper、DAO、分页插件、逻辑删除配置；
第三方服务：Redis缓存、邮件发送、文件上传、日志记录；
工具类：JSON解析、加密解密、日期处理、分页工具；
你的考试系统示例：QuestionMapper、PaperMapper、UserMapper、RedisUtil、JsonUtil

✔️ 第二层：应用层（Application）- 业务编排层，承上启下，无核心业务逻辑

核心职责：「调用领域层的服务+协调基础设施层」，完成业务流程的编排，比如“创建考试”的流程：创建考试实体 → 关联试卷 → 保存到数据库 → 发送通知。

✅ 核心原则：应用层只做「流程调用」，不做「业务规则判断」，业务规则全在领域层。
包含内容：应用服务（ApplicationService）、DTO（数据传输对象，接口入参出参）
考试系统示例：

ExamApplicationService：编排「创建考试」「发布考试」「学生参加考试」的流程；
PaperApplicationService：编排「手动组卷」「自动组卷」「发布试卷」的流程；
入参：CreateExamDTO、AddQuestionDTO；出参：ExamVO、PaperVO。

✔️ 第三层：领域层（Domain）- 核心层，灵魂层，所有业务规则都在这里，纯Java代码

核心职责：封装所有核心业务规则、业务逻辑、业务校验，是整个系统的「心脏」，不依赖任何其他层，不依赖任何框架，纯Java原生代码。
包含内容：我们第三步设计的「实体、值对象、领域服务」，仅此三类，无其他内容！
✅ 黄金原则：

领域层的代码，只关心业务，不关心技术，比如“判断考试是否开始”，只看startTime和当前时间，不关心怎么查数据库、怎么返回接口；
领域层的代码，可以脱离任何框架独立运行、独立测试，哪怕删掉SpringBoot，领域层的逻辑依然能跑通；
考试系统示例：Question(实体)、ExamConfig(值对象)、MarkingDomainService(领域服务)

✔️ 第四层：领域层内部 - 仓储层（Repository）- 领域层的「数据桥梁」

补充说明：仓储层是领域层的一部分，不是独立层，作用是：让领域层「不用关心数据怎么存、怎么查」，只关心业务逻辑。
仓储层定义「数据操作的接口」，由基础设施层的Mapper实现，比如：QuestionRepository接口定义「查询试题」，由基础设施层的QuestionMapper实现。

✅ 图文：四层架构调用关系（通俗易懂，一眼看懂）

前端请求 → 接口层(Controller) → 应用层(ApplicationService) → 领域层(Domain) → 仓储层(Repository) → 基础设施层(Mapper/Redis) ↑ ↓ └───────────────────────────────────────────────────────────────────────────────────────────────────────┘

✅ 核心规律：所有请求必须走这个链路，核心业务逻辑只在领域层，其他层都是配角。

✅ 第六步：代码落地 → 领域层核心实现示例（贴合你的表结构，可直接复制）

核心原则

所有代码的核心：领域模型驱动代码，业务规则写在领域层，其他层只做调用和数据传递。
这里给你写「最核心的3个示例」，覆盖实体、值对象、领域服务，你可以依葫芦画瓢完成所有代码，完全贴合你的表结构。

✔️ 示例1：领域实体 - Question（试题，对应question表）

// 纯领域实体，无任何框架注解，纯Java代码，只关心业务publicclassQuestion{// 对应表的字段（属性）privateLongid;privateStringstem;// 题干privateStringoptions;// 选项(JSON)privateStringanswer;// 正确答案privateLongknowledgeId;// 知识点IDprivateStringdifficulty;// 难度privateStringtype;// 题型privateBigDecimalscore;// 分值privateIntegerauditStatus;// 审核状态// 实体的业务行为（核心：业务规则封装在实体内部）// 行为1：校验学生答案是否正确publicbooleancheckAnswer(StringuserAnswer){returnthis.answer.equals(userAnswer);}// 行为2：判断试题是否审核通过publicbooleanisAudited(){returnthis.auditStatus==1;}// 行为3：获取试题分值publicBigDecimalgetScore(){returnthis.score;}// getter/setter 省略}

✔️ 示例2：值对象 - ExamConfig（考试配置，对应mock_exam表的exam_config字段）

// 值对象：无ID，无行为，只描述属性，不可变publicclassExamConfig{privateBooleanallowPause;// 允许暂停privateBooleanallowRetake;// 允许重考privateBooleanrealTimeJudge;// 实时判分privateIntegerautoSaveInterval;// 自动保存间隔// 值对象：构造方法全参，无setter，属性不可变publicExamConfig(BooleanallowPause,BooleanallowRetake,BooleanrealTimeJudge,IntegerautoSaveInterval){this.allowPause=allowPause;this.allowRetake=allowRetake;this.realTimeJudge=realTimeJudge;this.autoSaveInterval=autoSaveInterval;}// getter 省略}

✔️ 示例3：领域服务 - AnswerDomainService（答题判分，核心业务逻辑）

// 领域服务：处理跨实体的业务规则，核心业务逻辑全在这里@Service// 交给Spring管理，仅为了注入，无其他依赖publicclassAnswerDomainService{// 注入仓储（领域层不关心仓储的实现）@AutowiredprivateQuestionRepositoryquestionRepository;// 核心业务逻辑：客观题自动判分publicBigDecimalautoJudge(LongquestionId,StringuserAnswer){// 1. 获取试题实体Questionquestion=questionRepository.findById(questionId);// 2. 校验试题是否审核通过if(!question.isAudited()){thrownewBusinessException("试题未审核，无法判分");}// 3. 校验答案是否正确booleanisCorrect=question.checkAnswer(userAnswer);// 4. 返回得分returnisCorrect?question.getScore():newBigDecimal(0);}}