SYLLABUS · v2.0 已冻结
课程大纲
总纲 v2.0（2026-09-27 冻结）：此后只做文字勘误，不再做结构性调整。以下为大纲公开版提炼，完整教材按日陆续发布。
课程定位
为谁而设，教到哪里
- 目标学员：编程零基础或稍有了解，但希望真正掌握架构思维的人。
- 双重目标：① 通用——掌握通用软件架构设计理念与方法；② 专业——深入零售量化交易领域的软件架构设计。
专业边界声明：“专业”指零售量化交易系统（以 Alpaca API 为代表的券商 API 接入型系统），不覆盖机构级 HFT（FIX 协议、托管机房、做市策略、微秒级延迟优化）。该边界与学员基础及课程硬约束（单人运维、月预算 < $30）相匹配。
最终目标一句话：学员不是证明自己的架构“最好”，而是证明它在当前约束下是可解释、可验证、可恢复、可演进的。
毕业标准
毕业不是“知道 50 个架构术语”，而是：面对没见过的系统，知道先问边界是什么、状态在哪里、合同是什么、质量目标是什么、哪里会坏、为什么这么选、约束变化后设计是否还成立。
设计原则
课程的五条纪律
- 输入先行：每个新主题必须先有充分输入（讲解 + worked example），再要求学员输出。
- 提取与迁移：Recall 不可跳过；Apply 必须锚定交易场景。
- 约束驱动：一切设计决策必须在“单人运维 + $30/月预算”约束下论证。
- 安全优先：Safety Invariants 一票否决。
- 通用 → 专业 → 通用：先学通用概念，再进交易专业，最后用跨领域迁移验证通用性。
概念体系（教学简化框架 ↔ 行业术语）
| 课程概念 | 一句话定义 | 对应行业术语 |
|---|---|---|
| Boundary 边界 | 系统管什么、不管什么；外部依赖是谁 | 系统上下文（C4 Context）、约束 |
| Structure 结构 | 系统由哪些部分组成；职责是否清晰、内部是否高内聚 | 组件、模块（C4 Container / Component） |
| Interaction 交互 | 各部分如何交流 | 连接器、交互风格（同步调用 / 异步事件） |
| State 状态 | 系统如何记住“事情进展到哪一步”；状态如何合法转换 | 状态管理、一致性 |
| Quality 质量属性 | 除了“能跑”，还要跑得怎样 | 质量属性（Quality Attributes） |
| Trade-off 权衡 | 为什么选 A 不选 B；付出了什么代价；何时失效 | 架构决策记录（ADR） |
| Contract 横轴 | 接口契约：超时语义、幂等、所有权、有效期 | 接口契约、前后置条件、SLA |
不教清单（Scope Guard）：本课程不讲授 CAP、DDD、CQRS、Saga、Kubernetes、Event Sourcing、六边形架构等——防止术语堆积挤占基础能力训练。
14 天大纲
从词汇预科到模拟答辩
- Day 1预科：为什么需要架构 + 词汇表：核心定义；架构 / 设计 / 代码；Tom & Jerry 案例；18 个词汇。讲义 →
- Day 2需求工程 + Boundary：需求三分类；质量场景三问版；边界三件套与一句话契约。讲义 →
- Day 3Contract（上）：超时、幂等、所有权；为 Alpaca 下单接口写合同
- Day 4Structure + Interaction：同步 vs 异步；投递语义；C4 L1/L2 与 Mermaid；1 份 Mini ADR
- Day 5State + 订单状态机：Unknown / PendingResult 是合法状态
- Day 6Quality + Trade-off：质量场景模板；Trade-off 分析框架；完整 ADR
- Day 7检查点一：下单链路综合设计；Safety Gate + Green / Yellow / Red 三档（不计入最终成绩）
- Day 8Pre-Trade Risk 与交易安全开关：强制前置风控；Kill Switch 正确动作
- Day 9行情、时间、对账与审计：数据时效；对账作业；回测 / Paper / 实盘行为差异管理
- Day 10–11完整系统设计：完整 C4 图、订单状态机、Contract 清单、≥ 5 份 ADR
- Day 12架构验证方法 + 修订：“我们凭什么知道这个架构可能有效？”；故障桌面推演
- Day 13跨领域迁移：用同一套方法分析非交易系统（通过 / 不通过制）
- Day 14模拟答辩：七问答辩；Safety Gate → Architecture Score（100 分制）
节奏选项
- Recommended Track（推荐）：3–4 周，零基础默认选择。
- Intensive Track：14 天连续、每天约 1.5–2 小时，Bootcamp 式节奏。
- 不变量：任何节奏下，五阶段完整性规则、检查点顺序、Safety Gate 均不变。
教学协议
五阶段，一个都不能少
PHASE 1
Learn
讲解 + worked example；每节新概念 ≤ 3 个
PHASE 2
Recall
用自己的话复述；不可跳过
PHASE 3
Apply
迁移到交易场景；不可跳过
PHASE 4
Challenge
红队质询；不直接给完整方案
PHASE 5
Revise & Reference
先评估修订，再给标准参考
- 每个新主题首次教学必须完整走完五个阶段；复习可压缩 Learn，但不得跳过 Recall 与 Apply。
- 严禁在学员未完成当前主题的 Learn + Recall 之前，直接要求其进行完整系统设计。
安全底线
Safety Invariants · 一票否决
以下三条是任何架构方案下都必须永远成立的安全不变量。不变量规定的是“必须成立什么”，而不规定用哪种技术实现。
1. Pre-Trade Risk 是强制前置、不可绕过的决策
任何订单提交到券商之前，必须完成强制性风控检查；不得“先下单、再异步审查”。
2. 交易安全开关的目标是停止产生更多风险，而不是让系统失控
触发后正确动作永远是：禁止新单 → 尝试撤单（带幂等标识）→ 维持可观测。严禁直接杀死进程或断开所有监控。
3. 网络超时 ≠ 下单失败
必须进入 Unknown / PendingResult 状态；正确路径是先查询 → 核对 → 再决策；严禁把超时直接当成失败并盲目重发。Unknown is a valid state, not a failure of design.
统一实战场景
14 天只做这一个系统
全程锚定同一个小样场景，所有设计、图与 ADR 都必须回到它：
- 交易标的：SPY / QQQ（美股 ETF），1 分钟 K 线。
- 数据与券商：Alpaca Market Data API（WebSocket）；Alpaca Trading API（REST + WebSocket）。
- 风控约束：单笔最大 $5,000；日累计最大亏损 $300；连续 3 次（券商 / 异常）拒单触发交易安全开关。
- 运行环境：单人运维，1 台 2 核 4G 云服务器，月预算 < $30。
场景内延迟说明：1 分钟 K 线 + 单机场景下，延迟不是瓶颈；课程不讲授与此无关的低延迟优化，一切战术必须回扣预算与运维约束。
考核方式
先过安全门，再谈分数
Stage A — Safety Gate（一票否决）：先检查三条 Safety Invariants 是否全部满足；任意一条不满足 → 直接 Fail，不再进入后续评分。
Stage B — Architecture Score（100 分，仅通过 Safety Gate 后计算）
| 维度 | 权重 | 关键考察点 |
|---|---|---|
| Boundary & Contracts | 20% | 边界清晰，接口契约明确（超时、幂等、所有权、有效期） |
| State & Consistency | 20% | 状态机完整，含合法的 Unknown 状态，有查询对账路径 |
| Trade-off & Evolution | 20% | 能解释为什么选 A 不选 B，并给出可执行的演进条件 |
| Structure & Responsibilities | 15% | 职责边界清晰、内部高内聚，组件划分合理 |
| Quality Attributes & Tactics | 15% | 能从质量目标推导战术，区分功能需求与质量约束 |
| Communication / Documentation | 10% | 表达清晰，图与文字能支撑决策解释 |
Day 14 模拟答辩：七个问题
- 为什么系统这样拆分？
- 为什么这里用同步，那里用异步？
- 状态保存在哪里？如何保证一致性？谁拥有真实状态？
- 系统最重要的 failure modes 是什么？
- 哪些质量属性驱动了当前架构选择？
- 为什么没有选择另一种方案？付出了什么代价？
- 需求或约束变化后，架构如何演进？
图画得漂亮是加分项，解释权衡、合同与不变量才是核心。