第二部分 模式
用10个模式族、51个模式形成可反向检索的参考，并为每次选择记录适用条件、替代方案和代价。
学习目标
- 能用问题、语境和约束从10个模式族中定位候选，而不是按流行框架挑选51个模式
- 能用 TypeScript 记录模式机制、协作关系、替代方案、失败边界和验证证据
- 能在基线、临界和受控故障场景中复核模式选择，并说明何时撤回
为什么第二部分模式值得单独学习
第二部分模式不是采购清单，而是一套可检索参考：10个模式族、51个模式分别回答不同的业务和技术压力。模式名只有在当前问题、语境、力量、方案和结果都能对上时才有意义；同一个“服务”或“仓储”名词，也可能只是项目命名而不是模式证据。
↡把一组解决相近问题的模式组织在一起的分类，例如领域逻辑、数据源、Web 表示、分布和会话状态。帮助读者先定位问题空间，再比较同族候选。本页依据 2024 年中文版公开目录限定第二部分范围，并根据 Martin Fowler 的作者图书页和模式目录独立重写；目录只决定要讲什么，案例、实验、判断题和答案均为本课程原创。
↡一个模式改变责任、依赖、状态或数据流的具体方式，以及它带来的收益和新增成本。让评审从名字进入可观察的变化，而不是停留在术语层。
先建立直觉：选择必须可撤回
↡多个模式在同一个 Application Slice 中共同承担互补责任的关系，需要明确所有者、调用方向和失败传播。不是把模式数量最大化，而是解释组合为何能减少变化或风险。
↡与当前候选解决相同或相邻问题的其他方案，评审必须说明选择它们的条件以及拒绝当前候选的信号。让“为什么不用另一个模式”成为决策的一部分。
↡记录问题、上下文、候选、机制、证据、代价和拒绝条件的结构化评审结果，可由另一位复核者重放。把模式选择从口头偏好变成可审计、可撤回的假设。
对第二部分模式，优先比较的替代路线是：先写 Selection Problem，定位 Pattern Family，再比较 Pattern Mechanism 和 Collaborating Patterns，用 Alternative 与 Decision Record 完成取舍。若只展示成功路径，不记录代价和撤回条件，就不能据此选择第二部分模式。
目录单元到教学证据
第二部分模式
第二部分模式要求把参考目录变成可复核证据：冻结版次、应用切片与目录坐标；从问题与语境比较候选模式；手算远程、映射或冲突成本；验证正常样本与恰好边界；只注入一个故障并定位首差；让独立复核者重放并接入发布门禁。本文把这些证据映射到订单系统架构评审的反向索引和决策卡中。
专属代码案例：订单系统架构评审
把订单评审切成“问题识别 → Pattern Family → Pattern Mechanism → Collaborating Patterns → Alternative → Decision Record”六个观察点。设计草案必须写出谁拥有状态、谁作出业务决定、失败怎样传播，以及10个模式族、51个模式、使用时机、协作模式和失败边界中哪个指标最先提示当前方案不再适用。
设计记录采用五个可换行字段：单元键为 poeaa24-part-02-patterns；模式族为 book；裁决是“能按问题而非流行框架选择模式，并用基线、临界与受控故障场景验证”；观测项包括10个模式族、51个模式、使用时机、协作模式、失败边界；拒绝条件是“把目录节点或框架默认行为当成 Pattern Mechanism”。
先预测：订单查询出现重复数据库往返时，应该从数据源族、领域逻辑族还是分布族开始？先记录往返画像、聚合边界和部署关系，再列至少两个候选；验证时要能指出每个候选减少了什么，也要说明新增的复杂度。
type DecisionRecord = {
problem: string;
family: string;
candidates: string[];
mechanism: string;
evidence: string[];
alternative: string;
rejection: string;
};
function isReproducible(record: DecisionRecord): boolean {
return (
record.problem.trim().length > 0 &&
record.family.trim().length > 0 &&
record.candidates.length >= 2 &&
record.mechanism.trim().length > 0 &&
record.evidence.length >= 2 &&
record.alternative.trim().length > 0 &&
record.rejection.trim().length > 0
);
}这段代码把模式选择的最小证据合同固定下来：必须有问题、模式族、至少两个候选、机制、两项证据、替代方案和拒绝条件。它不替团队裁决，只保证评审不会在缺字段时伪装成确定结论。
10个模式族与51个模式
模式列表图用于建立全书参考坐标；它不要求读者逐个实现，而是帮助读者从一个问题反查模式族、候选和协作关系。
模式选择闭环
先从问题定位模式族，再比较机制、协作和替代方案，最后用基线、临界和受控故障验证。证据不支持收益时，应回退到更简单的方案，而不是继续增加模式。
选择与拒绝矩阵
| 评审问题 | 选择第二部分模式参考的证据 | 应拒绝当前方案的信号 |
|---|---|---|
| 定位 | Selection Problem 能指向明确 Pattern Family | 只按框架或团队习惯选族 |
| 机制 | Pattern Mechanism 对应可观察收益和成本 | 只读定义，无法说明改变了什么 |
| 协作 | Collaborating Patterns 的所有者与失败路径清楚 | 多个模式重复拥有状态或规则 |
| 取舍 | Alternative、证据和撤回条件都已记录 | 没有拒绝候选，默认永远保留复杂度 |
常见误区
可验证练习
练习
本组练习覆盖第二部分模式，并要求把问题、模式族、机制、替代和证据映射到订单评审。
问题 1：定位模式族。 订单查询的主要问题是跨进程调用次数过多，应该怎样开始检索？
问题 2：比较候选。 两个模式都能减少数据库访问，如何让评审具有可复核性？
问题 3：决定撤回。 模式在正常样本中略有收益，但故障恢复复杂度超过团队预算，是否仍应保留？
名词解释
名词解释
本章出现的专业名词，用大白话再讲一遍。
- Pattern Family
组织一组解决相近问题的模式分类，用于先定位问题空间再比较候选。
- Pattern Mechanism
模式改变责任、依赖、状态或数据流的具体方式及其收益和成本。
- Collaborating Patterns
多个模式在同一应用切片中承担互补责任的关系。
- Alternative
与当前候选解决相同或相邻问题、需要被比较并写出拒绝条件的方案。
- Decision Record
记录问题、候选、机制、证据、代价和拒绝条件的可复核评审结果。
本章小结
掌握第二部分模式的标志不是记住10个模式族和51个模式名称，而是能在订单评审中解释“问题 → 模式族 → 机制 → 协作 → 替代 → 决策记录”的责任链。学习者应利用使用时机、协作模式、失败边界和验证证据作出可证伪的选择，并在模式收藏、无替代比较和只验证成功路径时明确拒绝当前方案。
前后导航
来源与改写范围
- Martin Fowler 作者图书页：核对全书主题、教程与模式参考结构。
- Martin Fowler 模式目录：核对模式名称、所属模式族和作者公开摘要。
- Pearson 出版社页面：交叉核对英文版出版信息与目录范围。