📐 L1 建模层 = 被控对象的数学模型
解决什么问题：把现实世界的问题辨识为一个可被控制的数学对象—— 这个对象的边界、状态、动力学规律是什么。
在五层控制闭环中的角色
控制论视角的 L1：
─────────────────────────────────────────────────────
输入： 真实世界的问题
输出： 被控对象的数学模型（状态方程 / 传递函数 / 差分方程）
角色： "控制系统控制什么？" → 这是控制律的设计前提
─────────────────────────────────────────────────────
↓
L2 控制律设计
↓
L3 控制律实现
↓
L4 反馈调节
↑
闭环回到 L1（辨识偏差修正）L1 不是"画大饼"——它是"建立控制对象的数学描述"。
控制论核心：被控对象的数学描述
1. 状态方程（微分方程形式）
ẋ = f(x, u, t) ← 状态变化率 = f(当前状态, 控制量, 时间)
y = g(x, t) ← 观测 = g(状态, 时间)| 符号 | 含义 | 软件工程对位 |
|---|---|---|
| x | 状态向量 | 业务状态（订单状态、库存数） |
| u | 控制量 | 可被代码改变的输入（接口、命令） |
| ẋ | 状态变化率 | 业务状态变化的速度 |
| y | 观测 | 监控、日志、可观测性数据 |
| f | 动力学规律 | 业务规则、业务流程 |
| g | 观测函数 | 数据采集、监控埋点 |
2. 传递函数（频域形式）
Y(s) = G(s) · U(s)| 符号 | 含义 | 软件工程对位 |
|---|---|---|
| G(s) | 传递函数 | 系统对输入的响应特性 |
| U(s) | 输入 | API 调用、事件触发 |
| Y(s) | 输出 | 系统响应 |
关键：G(s) 决定了系统的所有动态行为——稳定性、过渡过程、稳态误差。
3. 差分方程（离散形式）
x(k+1) = A·x(k) + B·u(k)
y(k) = C·x(k)| 符号 | 含义 | 软件工程对位 |
|---|---|---|
| x(k) | 第 k 步的状态 | 定时任务、轮询状态 |
| u(k) | 第 k 步的控制 | 批量处理、定时命令 |
系统分类（Ch 1 §1.1-1.4）
控制论把所有被控对象分为四类：
| 类型 | 数学特征 | 软件工程对位 |
|---|---|---|
| 常系数线性 | 线性常 ODE，系数常数 | 单回路 CRUD / 标准业务 |
| 变系数线性 | 线性常 ODE，系数随时间 | 弹性扩缩 / 业务增长 |
| 非线性 | 含 y 或 y' 的高次项 / 乘积 | 含限幅 / 阈值的业务 |
| 分布参数 | 偏微分方程（无穷维） | 流式处理 / CDN / IoT |
关键：系统类型决定后续 L2-L4 的设计——选错类型 = 选错方法论。
辨识方法（Ch 1 §1.6）
把真实系统写成数学模型的三种方法：
| 方法 | 原理 | 软件工程对位 | 局限 |
|---|---|---|---|
| 解析法 | 物理定律拆解 → 联立 | 业务专家头脑风暴 | 复杂系统拆不出 |
| 实验测试法 | 加脉冲输入 → 测响应 → 反推 | 已有代码反推 / 混沌测试 | 噪声敏感 |
| 统计试验法 | 加随机输入 → 相关分析 | 日志反推 / 数据驱动建模 | 需高斯平稳假设 |
关键：建模的第一步是承认"模型 ≠ 现实"——模型只是简化，简化必有偏差。
性能指标定义（Ch 1 §1.7）
L1 的另一关键任务：定义系统好坏的六把尺子——
| 指标 | 控制论公式 | 软件工程对位 |
|---|---|---|
| 稳定性 | αᵢ<0（特征根实部为负） | 可用率 / SLO |
| 稳态精度 | x(∞)-x_ref | 准确性 / 一致性 |
| 过渡时间 | t₁-t₀ | 响应延迟 / P99 |
| 超调量 | σ = max|x|-x₁ / x₁ | 峰值流量 / 雪崩倾向 |
| 积分指标 | J = ∫f₀(x,u,t)dt | 综合 SLO |
| 抗扰性 | 干扰→误差传递函数 | 鲁棒性 / 容错 |
关键：L1 必须先定义指标，L2 才能据此设计控制器。
关键产出物（业务视角）
| 产物 | 它回答的问题 | 关键工具 |
|---|---|---|
| 领域 / 子域划分 | 这是哪类问题？核心域、支撑域、通用域 | 业务价值分析 |
| 限界上下文 | 模型的边界在哪里？ | 事件风暴 |
| 通用语言 | 这个上下文里"订单"到底指什么？ | 术语表 + 协作 |
| 上下文映射 | 上下文之间怎么协作？谁依赖谁？ | 上下文映射图 |
| 聚合 | 哪些对象必须作为一个整体被修改？ | 一致性边界分析 |
子主题（group 划分）
- 战略建模——视野最大的一层：领域、子域、限界上下文、通用语言
- 战术建模——视野下沉到代码单元：聚合、实体、值对象、领域服务
- 跨上下文协作——边界确定后，边界之间怎么打交道
- 工具与产物——事件风暴、上下文映射图、限界上下文画布
- 应用案例——端到端贯通的真实场景
阅读路径
新读者：
- L1 是什么（先看这篇） ← 你在这里
- 战略建模
- 战术建模
- 跨上下文协作
带着具体问题来的读者：直接进对应 sidebar group。
与其他层的关系
L1 建模 ──输出数学模型──► L2 设计
│
模型被翻译为
控制律（极点配置 + 性能指标）
│
▼
L3 实现- L1 是 L2 的前提：没有数学模型 = 没有控制律设计的基础
- L1 质量决定 L5 演化成本：边界模糊的模型，未来重构代价呈指数级
- L4 反哺 L1：运行数据会揭示建模假设的错误，需要回去修正模型
关键洞察
L1 是控制闭环的"被控对象"——控制律控制的就是这个对象。
钱学森 §1.5 原话："只有对控制量我们才有自由去改变它"—— L1 的核心任务就是识别哪些是可被控制的（控制量），哪些是只能被观测的（受控量）。
边界模糊的模型，未来 3 年的重构代价会呈指数级增长。 前 30% 的建模时间省下来了，后 300% 的实现时间会被消耗。
控制论对位
| 控制论概念 | 本层对应 |
|---|---|
| 被控对象 | 业务领域 / 系统边界 |
| 状态方程 ẋ = f(x, u, t) | 业务状态 + 业务规则 |
| 系统分类 | 业务类型（CRUD / 事件驱动 / 流式） |
| 辨识方法 | 建模方法（业务分析 / 数据驱动） |
| 质量指标 | NFR 定义 |
相关链接
IDDD 在 L1 的核心方法论
L1 建模层 = 把业务空间翻译为软件模型。IDDD Ch 1-3 给出"战略建模"的完整路径：
| 阶段 | 方法论 | 来源 |
|---|---|---|
| 问题识别 | 问题空间 vs 解决方案空间 | IDDD Ch 2 |
| 业务切片 | 子域分类（Core/Supporting/Generic） | IDDD Ch 2 ★★★★★ |
| 战略边界 | 限界上下文 | IDDD Ch 2 |
| 上下文关系 | 9 种 BC 关系 | IDDD Ch 3 ★★★★★ |
| 开发单元 | Module vs Bounded Context | IDDD Ch 9 |
| 战术建模 | 聚合 4 规则 | IDDD Ch 10 ★★★★★ |
L1 在 IDDD 中 = Ch 1-3 战略 + Ch 5-10 战术。
核心洞察：L1 建模层是"业务语言 + 数学语言"的双重翻译层——把业务问题翻译为软件模型（IDDD），把软件模型翻译为数学对象（cybernetics）。