前言 — remuse

界定企业应用、模式语言与 Duplex Book 读法，把叙述问题和模式目录连成可复核路径。

学习目标

能区分企业应用的问题语境、模式语言的经验抽象和具体框架实现
能用 Duplex Book 读法把叙述中的选择问题映射到模式目录与拒绝条件
能为一次订单系统评审记录问题、候选模式、证据和下一步验证，而不是直接套用名称

为什么前言值得单独学习

前言不是正文模式清单的缩略版，而是使用说明：企业应用先面对业务边界、数据一致性、组织责任和运行约束，再从反复出现的问题中提炼模式语言。读者必须知道哪些内容是问题叙述，哪些内容是候选方案，哪些内容还需要在自己的系统里验证。

不是“用了企业框架”的同义词。本文依据 2024 年中文版公开目录限定前言范围，并根据 Martin Fowler 的作者图书页和模式目录独立重写；目录只决定要讲什么，案例、实验、判断题和答案均为本课程原创。

把多个模式放回问题关系中，而不是把模式当作孤立的类名。

先建立直觉：两条阅读线互相校验

要求读者在叙述线和参考线之间来回，而不是从目录直接跳到实现。

没有语境，模式名称不能产生架构结论。

把“我觉得适合”变成可以被另一位复核者重放的判断。

对前言，优先比较的替代路线是：先从 Enterprise Application 的 Problem Context 出发，沿 Duplex Book 的叙述线和目录线寻找 Pattern Language，再用 Pattern Evidence 验证。若只背诵模式名、不记录拒绝条件和运行证据，就不能据此前言选择路径。

目录单元到教学证据

前言

前言要求把阅读方法变成可复核证据：冻结版次、应用切片与目录坐标；从问题与语境比较候选模式；手算复杂度、依赖和验证成本；验证正常样本与边界样本；只注入一个约束变化并定位首差；让独立复核者重放结果并接入发布门禁。本文把这些证据映射到订单系统架构评审的阅读卡和模式路径中。

专属代码案例：订单系统架构评审

把订单评审切成“Enterprise Application 问题 → Pattern Language 候选 → Duplex Book 导航 → Pattern Evidence → 复核裁决”五个观察点。设计草案必须写出谁拥有状态、谁作出业务决定、失败怎样传播，以及企业应用、模式语言、经验来源、使用方式和平台边界中哪个指标最先提示阅读路径不再可靠。

设计记录采用五个可换行字段：单元键为 poeaa24-preface；模式族为 book；裁决是“先描述选择问题，再用目录定位候选，最后用运行和测试证据验证”；观测项包括企业应用、模式语言、经验来源、使用方式、平台边界；拒绝条件是“把目录节点当成原文结论，或把框架默认值当成模式证据”。

先预测：订单系统的“状态复杂”究竟指领域规则、并发冲突、会话保存还是跨服务延迟？先写出问题上下文、候选模式和需要测量的证据，再阅读目录；验证时要能说明为什么进入某个模式族，也要说明为什么拒绝相邻候选。

type ReadingCard = {
  problem: string;
  context: string;
  candidates: string[];
  evidence: string[];
  rejection: string;
};
 
function isReviewable(card: ReadingCard): boolean {
  return (
    card.problem.trim().length > 0 &&
    card.context.trim().length > 0 &&
    card.candidates.length >= 2 &&
    card.evidence.length >= 2 &&
    card.rejection.trim().length > 0
  );
}

这段代码把 Duplex Book 的读法变成最小评审卡：先写问题和上下文，再列至少两个候选、两项证据和一条拒绝条件。它不会替团队决定模式，只防止团队在没有语境和证据时过早结束讨论。

全书模式语言地图

全书模式族不是平面清单。基础模式支撑领域逻辑、数据源、Web 表示、分布、并发和会话状态；阅读者应从问题出发沿依赖关系前进，再回到目录核对模式之间的替代与互补关系。

全书 51 个模式分为 10 个族，基础模式（Gateway / Mapper / Registry 等）支撑所有其他族。学习路径：基础 → 领域逻辑 + 数据源 → 对象关系 → Web / 分布 / 并发 / 会话。

Duplex Book 阅读循环

先从叙述线提取 Problem Context，再从目录线列出候选模式，最后用 Pattern Evidence 复核并记录拒绝条件。任何一步无法解释，都回到问题而不是跳到框架 API。

Duplex Book 把叙述理解、目录导航与项目验证连成循环，避免从模式名直接跳到实现。

选择与拒绝矩阵

评审问题	选择前言阅读路径的证据	应拒绝当前记录的信号
问题	Enterprise Application 的责任、变化和失败被写清楚	只有产品或框架名称，没有业务问题
关系	Pattern Language 能解释候选之间的替代与互补	把每个模式当成独立采购清单
阅读	Duplex Book 在叙述线与目录线之间来回核对	从目录节点直接跳到实现代码
验证	Pattern Evidence 可测量、可复核且包含拒绝条件	只凭经验声称“这个模式更优雅”

常见误区

可验证练习

练习

本组练习覆盖前言，并要求把企业应用问题、模式语言、Duplex Book 和证据记录映射到订单评审。

问题 1：先写问题。 团队说“订单系统需要领域模型”，第一步应该补问什么？

问题 2：使用 Duplex Book。 叙述线说明某个页面需要共享导航，目录线却列出多个 Web 表示模式，如何继续？

问题 3：判断证据。 “框架默认开启事务”能否证明订单提交不会出现并发冲突？

名词解释

本章出现的专业名词，用大白话再讲一遍。

Enterprise Application: 围绕业务流程、数据和组织责任运行，并需在长期变化中保持可靠性的软件系统。
Pattern Language: 用问题、语境、力量、方案和结果描述可重复架构经验的共享词汇。
Duplex Book: 将问题叙述与模式目录并排阅读、互相核对的学习方式。
Problem Context: 决定模式是否有意义的业务、技术、组织和时间条件。
Pattern Evidence: 支持或否定模式选择的可观察记录，例如指标、测试和失败路径。

本章小结

掌握前言的标志不是记住几个阅读术语，而是能在订单系统架构评审中解释“问题 → Pattern Language → Duplex Book 导航 → Pattern Evidence → 复核裁决”的责任链。学习者应利用企业应用、模式语言、经验来源、使用方式和平台边界作出可证伪的阅读选择，并在模式清单化、只看目录和把框架默认值当证据时明确拒绝当前记录。

前后导航

来源与改写范围

Martin Fowler 作者图书页：核对全书主题、教程与模式参考结构。
Martin Fowler 模式目录：核对模式名称、所属模式族和作者公开摘要。
Pearson 出版社页面：交叉核对英文版出版信息与目录范围。