引言 — remuse

定义架构、企业应用类型、性能约束与模式表达，建立全书共同语境。

学习目标

能用 Architecture、Enterprise Application、Application Type、Performance Budget 与 Pattern 说明一次系统评审的共同语境
能用 TypeScript 把订单系统的边界、请求路径和性能预算写成可复核的评审卡
能根据业务责任、部署形态、性能约束和失败证据选择模式族，并明确拒绝条件

为什么引言值得单独学习

引言不是全书模式名称的目录预览，而是建立判断坐标：什么是架构边界，什么是企业应用，应用类型如何改变约束，性能如何成为设计输入，模式又如何表达可重复的经验。缺少这些坐标时，读者很容易把“分层”“事务”或“服务”当成不需要语境的答案。

不是一张静态部署图，而是对变化和失败负责的约束集合。本页依据 2024 年中文版公开目录限定引言范围，并根据 Martin Fowler 的作者图书页和模式目录独立重写；目录只决定要讲什么，案例、实验、判断题和答案均为本课程原创。

的难点不是页面数量，而是业务规则和系统责任会持续变化。

先建立直觉：类型和预算先于模式

例如事务处理、批处理、集成服务或交互式 Web 应用，都会改变可接受的等待和一致性策略。

把“快一点”变成端到端请求、数据库往返和队列等待的具体目标。

不是框架类名，也不是必须照搬的模板；它要在当前约束中用证据重新验证。

对引言，优先比较的替代路线是：先明确 Architecture 和 Enterprise Application 的责任，再辨识 Application Type，写出 Performance Budget，最后用 Pattern 表达候选方案。若实验只能展示结果却不能说明预算、依赖方向和失败路径，就不能据此选择模式族。

目录单元到教学证据

引言

引言要求把共同语境变成六组可复核证据：冻结版次、应用切片与目录坐标；从问题与语境比较候选模式；手算远程、映射或冲突成本；验证正常样本与恰好边界；只注入一个故障并定位首差；让独立复核者重放并接入发布门禁。本文覆盖 0.1 架构、0.2 企业应用、0.3 企业应用的种类、0.4 关于性能的考虑和 0.5 模式等目录节点。

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

把订单系统评审切成“架构边界 → 应用类型 → 业务责任 → 性能预算 → 模式选择”五个观察点。设计草案必须写出谁拥有订单状态、谁作出业务决定、失败怎样传播，以及架构、企业应用、应用种类、性能和模式中哪个指标最先提示当前方案不再适用。

设计记录采用五个可换行字段：单元键为 poeaa24-introduction；模式族为 book；裁决是“能判定一个系统是否属于本书讨论的企业应用，并写出架构和性能边界”；观测项包括架构、企业应用、应用种类、性能、模式；拒绝条件是“把目录节点或框架默认值当成架构证据”。

先预测：订单详情接口要求 p95 小于 250ms，但当前链路包含三个远程调用和两次重复查询，先换模式还是先量化预算？先写出端到端路径、每段预算和失败恢复，再阅读模式；验证时要能说明一次优化减少了哪项成本，也要说明引入的间接层。

type ArchitectureCard = {
  applicationType: "transactional" | "batch" | "integration";
  p95BudgetMs: number;
  remoteCalls: number;
  databaseQueries: number;
  owner: string;
  rejection: string;
};
 
function reviewArchitecture(card: ArchitectureCard): string[] {
  const findings: string[] = [];
  if (card.p95BudgetMs <= 0) findings.push("缺少性能预算");
  if (card.remoteCalls > 2) findings.push("需要评估远程往返");
  if (card.databaseQueries > 3) findings.push("需要评估查询画像");
  if (!card.owner.trim()) findings.push("缺少责任所有者");
  if (!card.rejection.trim()) findings.push("缺少拒绝条件");
  return findings;
}

这段代码把引言的评审语境变成结构化记录：它不会替团队选模式，但会暴露没有预算、责任或拒绝条件的空白。真正的模式选择还必须用正常样本、边界样本和单故障注入验证。

企业应用三层架构

三层架构图展示表示、领域和数据源的职责边界，以及上层依赖下层的方向。它是讨论模式的共同坐标，不是要求所有系统机械拆成三层。

企业应用经典三层：表示层处理交互，领域层封装业务规则，数据源层负责持久化。依赖方向严格向下，上层通过接口调用下层，下层对上层一无所知。

层与部署位置

同一组逻辑层可以部署在一个进程，也可以跨应用服务器和数据库服务器分布；部署变化会引入网络、序列化和失败成本，因此必须回到 Performance Budget 验证。

逻辑层到物理节点的映射不是固定的。单体应用三层同进程；经典部署把表示+领域放在应用服务器；微服务则进一步拆分领域层。选择取决于团队规模、流量和运维能力。

选择与拒绝矩阵

评审问题	选择引言阅读路径的证据	应拒绝当前记录的信号
架构	责任、变化和依赖方向被写清楚	只有框图，没有所有者和失败路径
类型	Application Type 解释了交互、数据和部署约束	把所有系统都套成同一种应用
性能	Performance Budget 分配到远程、数据库和队列	只说“需要更快”，没有可测量上限
模式	Pattern 候选有收益、代价和拒绝条件	看到熟悉名词就直接引入框架组件

常见误区

可验证练习

练习

本组练习覆盖引言，并要求把架构、应用类型、性能预算和模式证据映射到订单评审。

问题 1：判断应用语境。 一个每日凌晨运行、处理百万条记录、允许重跑的对账程序，是否应直接按交互式订单服务的延迟预算设计？

问题 2：分配性能预算。 订单详情 p95 预算为 250ms，链路包含两个远程调用和三个数据库查询，下一步应怎样验证？

问题 3：验证模式选择。 团队选择某个模式后只跑成功路径，如何补齐证据？

名词解释

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

Architecture: 决定组件、责任、依赖和运行边界如何组织并随变化演化的高影响结构选择。
Enterprise Application: 围绕业务流程、数据和组织责任运行，并需长期保持可靠性的系统。
Application Type: 描述系统交互方式、数据边界、部署关系和组织责任的分类。
Performance Budget: 为延迟、吞吐、并发、资源和失败恢复设置的可测量上限。
Pattern: 以问题、语境、力量、方案和结果表达可重复架构经验的共享词汇。

本章小结

掌握引言的标志不是记住几张架构图，而是能在订单系统评审中解释“架构边界 → 应用类型 → 业务责任 → 性能预算 → 模式选择”的责任链。学习者应利用架构、企业应用、应用种类、性能和模式作出可证伪的选择，并在没有责任、预算、失败路径或拒绝条件时明确拒绝当前方案。

前后导航

来源与改写范围

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