模式列表
以10个模式族组织51个模式，建立从问题、适用条件到协作模式和替代方案的反向索引。
学习目标
- 能根据一个架构问题定位到对应的模式族，并说出该族内至少两个模式的适用条件差异
- 能比较同一模式族内的两个候选模式，记录拒绝理由和替代方案
- 能对一道模式选型题走完"问题分类→模式族→候选模式→协作关系→取舍复核"的判断链
先建立直觉：问题、机制与代价
先猜一猜：两个团队都遇到了"业务规则分散在多个地方"的问题，一个选了事务脚本，一个选了领域模型，谁能更快地应对需求变化？
模式列表 面对的具体压力是"单元覆盖、跨族依赖与可追溯来源"。它采用的机制可以概括为：以10个模式族组织51个模式，建立从问题、适用条件到协作模式和替代方案的反向索引。机制带来的收益必须与新增间接层、同步责任或迁移成本同时记录，否则学习者只会得到一个没有拒绝条件的模式名称。
对 模式列表，优先比较的替代路线是：按真实问题进入模式族，而不是把模式名称当作采购清单。本页的通过条件是"能从一个架构问题定位候选模式族，比较至少两个模式并记录拒绝理由"；若实验只能显示结果而不能指出 51个模式 从何处越界，就不能据此选择 模式列表。
目录单元到教学证据
本书的 51 个模式分布在 10 个↡中，每一个模式族解决一类特定的架构问题。要有效使用这份模式列表，需要理解三个层次的组织逻辑。
问题分类是第一入口
面对一个架构问题时，第一步不是翻开模式列表逐个比对，而是先对问题进行分类：是领域逻辑的组织问题，还是数据源的映射问题，或者是 Web 表现的布局问题？↡决定了你应该进入哪个模式族。
模式族内比较候选模式
定位到模式族后，族内通常有多个候选模式。例如"领域逻辑模式"族包含事务脚本、领域模型、表模块和服务层四个模式。选择的依据不是"哪个更流行"，而是"当前问题的上下文适合哪个"——需要从业务复杂度、团队技能、测试策略和部署方式等维度综合判断。↡之间的比较需要记录拒绝理由，而不是凭感觉选一个。
协作关系与取舍复核
模式不是孤立使用的。一个订单系统可能同时用到事务脚本（领域逻辑）、表数据入口（数据源）和模板视图（Web 表现），这三个模式之间的↡决定了数据如何在层之间流动。最后一步是↡：确认选定的模式组合在整体架构中是否一致，是否存在责任重叠或空白。
模式族索引
常见误区
专属设计案例：订单系统架构评审
把 订单系统架构评审 切成"问题分类 → 模式族 → 候选模式 → 协作关系 → 取舍复核"五个观察点。模式列表 的设计草案必须写出谁拥有状态、谁作出业务决定、失败怎样传播，以及 51个模式、10个模式族、问题索引、协作图、替代方案 中哪个指标最先提示当前方案不再适用。
设计记录采用五个可换行字段：单元键为 poeaa24-pattern-list；模式族为 book；裁决是"能从一个架构问题定位候选模式族，比较至少两个模式并记录拒绝理由"；观测项包括 51个模式、10个模式族、问题索引、协作图、替代方案；拒绝条件是"51个模式 超过团队为 模式列表 设定的边界"。
配置不是生产框架语法，而是一张评审卡。对 模式列表 的任何实现都要能把运行证据重新映射到这张卡；如果更换 ORM、Web 框架或部署平台后无法回答同一组问题，说明决定依赖的是工具偶然行为而不是模式语义。
选择与拒绝矩阵
| 评审问题 | 选择 模式列表 的证据 | 应拒绝或改用其他方案的信号 |
|---|---|---|
| 责任 | 问题分类 到 取舍复核 的所有者清晰 | 模式族 可以绕过边界直接改写状态 |
| 变化 | 51个模式 的变化被局部吸收 | 一次小改动同时触及 10个模式族、问题索引、协作图 |
| 失败 | 故障能在 取舍复核 前被识别并回退 | 只能看到最终错误，无法定位 51个模式 的首个异常 |
| 替代 | 已与同族候选比较并保留撤回路径 | 因框架内置或团队习惯而跳过问题分析 |
本章小结
- 51 个模式按 10 个模式族组织，每个模式族解决一类特定的架构问题。
- 使用模式列表的正确顺序是：问题分类→模式族→候选模式→协作关系→取舍复核。
- 模式族内比较必须记录拒绝理由，不能凭熟悉度选型。
- 选择与拒绝矩阵帮助你在真实项目中做出可证伪的架构决定。
- 模式是协作使用的，选型时需要考虑模式之间的组合一致性。
本章练习
练习
问题 1： 团队遇到"业务规则分散在多个控制器中，没有统一的位置"的问题。应该先定位到哪个模式族？该族内有哪些候选模式？
问题 2： 假设你在"数据源架构模式"族内，需要在表数据入口和行数据入口之间做选择。列出至少两个比较维度。
问题 3： 团队说"我们用活动记录模式，因为框架默认就是这样的"。如何用选择与拒绝矩阵来评估这个决定？
出处声明
名词解释
名词解释
本章出现的专业名词，用大白话再讲一遍。
- 模式族
- 将解决同一类问题的相近模式归为一组，帮助读者理解方案之间的替代与互补关系，例如"领域逻辑模式"族包含事务脚本、领域模型、表模块和服务层。
- 问题分类
- 面对架构问题时，先对问题进行分类（领域逻辑、数据源映射、Web表现等），确定应进入哪个模式族。
- 候选模式
- 在同一个模式族内有多个可选模式，需要根据具体上下文比较选择，并记录拒绝理由。
- 协作关系
- 多个模式在同一个系统中如何配合工作，每个模式在协作中承担什么责任、数据如何在层之间流动。
- 取舍复核
- 选型完成后，确认选定的模式组合在整体架构中是否一致，是否存在责任重叠或空白。