材料齐了，7 个来源全部打开核实过原文。下面是这份补全文档。
值得看的情形：你写过"函数里先查库、再 if 判断、出错抛 HTTPException"的 CRUD 代码，隐约觉得哪里不对却说不出为什么；或者你刚听说"分层""依赖倒置""依赖注入"这些词，想要一个 7 分钟内能跑通的完整例子。这条视频用一个"课程报名"用例，把上面所有概念各给了一个最小可运行的落点，完整度在同长度视频里少见。
可以跳过的情形：你已经读过《Clean Architecture》或用过端口与适配器模式——视频的全部内容都是这套思想的入门演示，没有超出书本的新观点。另外视频开头"AI 在编程上的设计能力基本为 0"是博眼球的个人断言（详见下文"存疑点"），不必被它带着走；视频结尾有下集（agent 项目分层）的钩子，本条不包含该内容。
一个提醒：这是全程写代码的演示型视频，信息密度高、几乎没有废话，但也没有慢速铺垫——初学者可能需要暂停跟做，而不是"听"完。
起点：一段"能跑但有问题"的 AI 生成代码。 UP 主让 AI 实现课程报名，AI 给出的方案是：从数据库取数据 → 写几个 if 判断 → 根据判断结果抛 HTTPException 或把结果存回数据库。UP 主指出三个问题：
方法：按"责任"拆四层，并定死依赖方向。 UP 主先问"这个用例里存在哪些责任"，然后拆成四层，并按"容易变化的层依赖不容易变化的层"排出依赖链：
| 层 | 职责 | 变化频率 |
|---|---|---|
| API | 定义 endpoint，告诉前端调什么 | 易变（Flask 换 FastAPI） |
| DB | 增删改查 | 易变（SQLite 换 PostgreSQL） |
| Service | 编排流程：何时调 DB、何时调领域规则 | 居中 |
| Domain | 领域规则：什么情况报名成功/失败 | 不易变（"人满了报不上名"与技术无关） |
依赖方向为：DB 和 API 依赖 service，service 依赖 domain。
逐层实现的几个关键决策：
Student（id、name）和 Course（id、容量、已选学生 roster）两个类；enroll（报名）行为放在 Course 里，因为报名主要改动 Course 的属性——容量已满抛"课程已满"异常，学生已在 roster 里抛"已报名"异常，否则 append 进 roster。UP 主特意说明建模方式不唯一，enroll 也可以放在类外面，"取决于具体用例"。course.enroll() → 保存结果。视频在这里抛出并回答了一个好问题：DB 还没实现，凭什么知道它有哪些方法？ 答案是接口由 service 层定义——用 Python 的 ABC 和 @abstractmethod 声明 Database 抽象类，要求任何实现（SQLite 也好 PostgreSQL 也好）必须提供 get_student、get_course、save_course 三个方法。Database 并实现三方法；又另写一个 PostgreSQL 实现同样实现三方法——换库时 service 一行不改。UP 主在这里点名"依赖倒置"，并演示"改一行代码把项目从 SQLite 换成 PostgreSQL"。enroll endpoint；domain 里定义的异常在这一层被翻译成 HTTPException 供外部使用；service 不在此层构造，而是作为参数传入——UP 主点名"依赖注入"。收尾：UP 主两次坦白，为了展示用例被刻意做小，重构后"代码更多、文件更多、看起来更复杂"，真实项目中这样做利大于弊。
下集预告：用同一套思路写一个 agent 项目，讨论 agent 要怎么分层、harness 放在哪一层。
转写稿对照提示：本文引用时已纠正语音转写错误——"用力"=用例、"q口"=SQL、"doomain"=domain、"EVC"=ABC、"sqol line"=SQLite、"postg/post gray"=PostgreSQL、"roasster"=roster。
1. "依赖倒置"的正式出处。 UP 主口述的定义是准确的：该原则由 Robert C. Martin 于 1996 年在《C++ Report》专栏提出，是 SOLID 里的 "D"，两条规则为：高层模块不应依赖低层模块，两者都应依赖抽象；抽象不应依赖细节，细节应依赖抽象 [1]。视频里"service 定义 Database 接口、DB 层反过来 import 这个接口"正是该原则的教科书操作——抽象的所属权在高层，这使得依赖箭头与调用箭头方向相反，故名"倒置" [1]。
2. 视频那套 Database 接口，学界/业界叫"端口与适配器"。 Alistair Cockburn 2005 年提出的六边形架构（Ports and Adapters）主张：应用通过叫"端口"的接口与外部组件通信，每种具体技术（REST、数据库）写一个"适配器"插到端口上 [3]。AWS 的官方模式文档对此的定义与视频的 Database 抽象一一对应：端口是技术无关的入口，适配器负责把具体存储技术翻译过来；换适配器不动端口 [3]。它还有一个更常见的名字是"仓储模式"。
3. 四层与 Clean Architecture 的对应关系。 Uncle Bob 2012 年总结的 Clean Architecture 与六边形、洋葱架构同源，共同目标是关注点分离，其核心"依赖规则"是：源代码依赖只能向内指向，内圈对任何外圈的名字一无所知 [2]。四圈从内到外为 Entities（企业级业务规则）、Use Cases（应用级业务规则，负责编排实体）、Interface Adapters（转换数据格式）、Frameworks & Drivers（Web 框架、数据库等"细节"）[2]。对照视频：domain≈Entities，service≈Use Cases，API 和 DB≈外两圈——视频讲的其实是 Clean Architecture 的最小可用子集，且省略了内圈的"输出端口"等细节。
4. 组装器在 DI 文献里的名字：Composition Root。 Mark Seemann 的定义："Composition Root 是应用中一个（最好）唯一的、把模块组装起来的位置"，应尽可能靠近应用入口点；只有入口点才组装整个对象图，其余代码只声明依赖、从不组装 [4]。视频"唯一 new 对象的地方"就是这个模式的通俗说法；手工 new 而不用 DI 容器的做法 Seemann 称为 Pure DI [4]。
5. 视频先后用了"依赖倒置"和"依赖注入"两个词，它们不是一回事。 TU Delft 的课程材料区分得很清楚：依赖倒置是类如何设计的问题（哪些该做成抽象），依赖注入是对象如何拿到它依赖的东西的问题 [5]。视频里 Database 抽象是倒置，service 作为参数传进 API 层是注入。
6. FastAPI 其实自带一套 DI 容器，视频没有用它——这是有意的取舍。 FastAPI 官方文档明确它有"非常强大而直观的依赖注入系统"，路径操作函数用 Depends() 声明所需依赖，框架负责构造并注入 [6]。视频选择手工组装而非 Depends，好处是组装逻辑全部显式地落在组装器里、不依赖框架魔法；代价是写法更啰嗦。两种都是依赖注入，读者不要把视频写法误认为 FastAPI 的惯用法。
7. ABC + @abstractmethod 为什么能"强制"实现。 Python 官方文档确认：元类为 ABCMeta 的类（或继承自 ABC 的类），只要还有抽象方法或属性未被覆写，就无法被实例化 [7]。也就是说，"强制"发生在运行时实例化的瞬间，而非静态检查——漏实现方法的子类在 import 时不报错，直到 SqliteDB() 被调用才抛 TypeError。
save_course）也隐含了"course 的 roster 整体覆盖式保存"，这在多人同时报名时需要乐观锁/版本号配合，视频未涉及。Database 抽象不互斥；行业里常见做法是 ORM 管 SQL 方言、抽象接口管"测试替身"（在单测里塞内存假实现），这是对视频"换库"动机的补充理解（推断）。（来源 1–7 均已打开原文核对；视频本身的陈述以上文"视频讲了什么"一节为准，不随来源增删。）