Learning Record 0003 — 三条支线共享同一根因：集中式单体

状态：洞察（synthesis），由 Lesson 0007/0008/0009 串联得出，待复核。

非显而易见的事实

风险（0007）、监管（0008）、架构（0009）三条支线看似独立，实则共享同一个根因：ODTS 是围绕一个共享 Oracle schema 的集中式单体，服务间靠文件轮询/异步集成，且有两套定价引擎。

具体链条（这是单独看任一节都看不到的）：

SAC 2021 初始保证金规则（0008）
  → 要求 MarginCalculator 增 SIMM（算 IM）
  → MarginCalculator 跑在共享 Oracle 上（0009）
  → 共享库任意表字段变更会触发 EOD 旧 SQL 异常（2019 remark 事故，0009）
  → 风险度量 PFE/IM（0007）的落地成本被架构放大：
     "监管要求收 IM" 在 ODTS 里不是加个字段，而是动整个 EOD 链

推论（对 PM/BA 有用的判断框架）

1. “改个字段要 3 天” 不是团队慢，而是共享 schema + 文件集成 + 无版本兼容检查（tradedesign proto）共同导致的。任何跨服务变更都需协调 45+ 项目。
2. 监管要求的落地成本被架构放大：SAC/ISDA 每次加字段（CVA 2020、IM 2021），都要在共享库上动刀，风险与 EOD 稳定性直接受牵连。
3. 微服务拆不动的真因：cash-manager 死、report-processing 活——差别只在”数据库是否独立”。这把”架构债务”从抽象概念变成可操作的验收问题：拆之前先问”DB 独立吗？逻辑独立吗？“

对教学的用法

在 Lesson 0009 收口时，用这条链把 0007/0008 的”风险度量""监管报送”挂回”架构负债”，让学生理解：前面学的每个流程都不是孤立跑的，它们都躺在那张共享库上。这也能回答用户最早的问题”为什么改个字段要 3 天”。

待复核

• 未核对 sac-report 的 MarginCalculator 是否确实读写同一 EDS schema（ODTS-09 概说”服务读写同一 Oracle”，但需确认 MarginCalculator 具体实现）。
• PFE（0007）与 SAC IM（0008）的字段映射是否同一套，未逐一比对源码。