用AI学习“工程化思考”——第一阶段学会拆解之架构讲解员

题目：请你当一次“架构讲解员”

背景

公司现在有一个在线学习平台，核心功能包括：

• 学生选课、学习课程
• 老师发布课程、更新内容
• 平台记录学习进度
• 管理员能查看整体数据

目前系统是单体应用，团队 5 人，已经跑了 2 年。

最近出现几个现实问题：

• 新需求越来越慢
• 改一个功能，经常影响别的地方
• 新人要 2 个月才能“敢动代码”
• 老师那边抱怨：课程一多，系统就卡

老板问你一句非常工程味的问题：

“这个系统的结构问题到底在哪？”

你的任务（请按顺序回答）

请你假设你要给一个新同事讲清楚这个系统，回答下面这些问题即可，不需要画图，用语言。

1️⃣ 你会把这个系统拆成哪几个“结构块”？

（不是类，不是表，是“职责块”）

• 每一块一句话说明它干什么
• 不要超过 6 块（多了说明没抓住结构）

2️⃣ 哪一块是“最核心、最怕动”的？为什么？

（说清楚一动会发生什么）

3️⃣ 哪些地方最可能成为性能或复杂度的爆点？

（不用优化方案，只说“哪里危险”）

4️⃣ 如果只允许你做一件事来“让系统没那么痛苦”，

你会优先动哪里，为什么？

注意：

• 不许说“全面重构”
• 不许说“上微服务”
• 必须是工程上真实可落地的一步

评分标准

你不需要“对”，只需要做到这几点：

• 你拆的是职责，而不是技术
• 你能明确说出哪里怕、为什么怕
• 你能解释你的取舍，而不是“感觉更好”

好，我给你一份**“工程化视角下的标准示例答案”。
先说清楚：这不是唯一正确解，而是“如果一个有经验的架构师来给新人讲这套系统，大概率会这么讲”**的版本。

你可以对照着看三件事：
他在先讲什么、怎么解释因果、哪里在克制技术冲动。

下面是答案

一、结构拆解（示例答案）

1️⃣ 课程与内容管理

负责课程的创建、组织、发布，以及课程内容的版本变化。

这是老师“能不能把东西教出来”的地方，决定了平台上“有什么可学”。

2️⃣ 学习过程与进度管理（核心）

负责记录学生在课程中的学习状态、进度、完成情况。

这是平台的“记忆系统”，决定学生学到哪、有没有学过、能不能继续。

3️⃣ 测验与评估

负责作业、测验、考试的规则、提交、判定与结果。

这是学习成果的裁判，规则多、状态复杂、并发集中。

4️⃣ 用户与角色管理

负责区分学生、教师、管理员，并控制他们能做什么。

这是平台的秩序维护者，本身不创造学习价值，但决定混不混乱。

5️⃣ 数据统计与审计

负责记录行为、统计数据，为管理和分析提供依据。

这是“事后看”的能力，不影响主流程，但对运营和追责重要。

二、最核心、最怕动的部分（示例答案）

学习过程与进度管理是最核心、最怕动的部分。

原因不是它“复杂”，而是：

• 所有课程内容都要被“学习进度”消费
• 测验结果要回写学习状态
• 统计数据以它为事实基础

一旦进度模型变化：

• 历史数据可能失真
• 规则判断会全部受影响
• 老课程、新课程的兼容性会出问题

这是典型的**“业务事实中心”**，动它等于动地基。

三、最可能成为性能或复杂度爆点的地方（示例答案）

测验与评估流程是最大的风险点。

因为它同时具备：

• 高并发（集中考试）
• 多状态（开始、提交、超时、补交）
• 强一致性需求（成绩、判定）
• 规则频繁变化（考试策略）

这类模块往往一开始能跑，
一旦规模上来，就会同时拖慢性能和开发效率。

四、只做一件事，缓解痛苦（示例答案）

先冻结学习进度与测验的“业务边界”，明确不可随意修改的核心模型和接口。

具体做法不是重构，而是：

• 明确哪些字段、状态是“业务事实”，不允许随意扩展
• 把测验规则从流程代码中抽离，避免每次需求都改主流程
• 控制变更半径，让新增需求只能在边界外发生

这一步的目标不是“更先进”，而是：
让系统不再每改一次就全身疼。