第18章 基本模式

为什么第18章基本模式值得单独学习

基本模式不是一组可以无条件堆叠的工具类，而是隔离变化轴的小型构件。订单系统要从旧仓储迁移到新 API 时，真正重要的问题不是“再加一个 Service 类”，而是调用者是否依赖了外部表示、对象创建方式和全局查找细节。

把外部变化留在边界内。本页依据 2024 年中文版公开目录限定第18章范围，并根据 Martin Fowler 的作者图书页和模式目录独立重写；目录只决定要讲什么，案例、实验、判断题和答案均为本课程原创。

避免把数据库行、远程 JSON 和领域对象混成一个不稳定的类型。

先建立直觉：小边界，大责任

适合确实需要运行时发现或共享生命周期的场景，不应成为默认的全局依赖入口。

只有当层内规则稳定且确实需要共享时才值得引入。

让领域层定义需要的端口，而不是让基础设施决定领域层的抽象。

对第18章基本模式，优先比较的替代路线是：存在外部变化时使用 Gateway，存在对象表示变化时使用 Mapper，需要运行时发现时谨慎使用 Registry，层内规则稳定时才采用 Layer Supertype，跨包依赖需要由使用者控制时采用 Separated Interface。若没有明确变化轴却先创建全局入口、抽象工厂和多层映射，就不能据此选择基本模式。

目录单元到教学证据

第18章基本模式

第18章基本模式要求把构件选择变成可复核证据：冻结版次、应用切片与目录坐标；从问题和语境比较候选模式；手算转换和间接层成本；验证正常样本与边界样本；只注入一个替换故障并定位首差；让独立复核者重放结果并接入发布门禁。本文把这些证据映射到订单存储替换的端口、适配器、映射测试和依赖检查中。

专属代码案例：订单系统基础设施替换

把订单查询切成“用例 → Separated Interface → Gateway → 外部记录 → Mapper → 领域对象”六个观察点。设计草案必须写出谁拥有领域规则、谁负责表示转换、失败怎样传播，以及依赖方向、对象语义、配置、测试隔离和表示转换中哪个指标最先提示方案不再适用。

设计记录采用五个可换行字段：单元键为 poeaa24-chapter-18-base-patterns；模式族为 base；裁决是“让领域端口拥有语义，让 Gateway 和 Mapper 吸收基础设施变化，并让替换失败可在边界被定位”；观测项包括依赖方向、对象语义、配置、测试隔离、表示转换；拒绝条件是“全局 Registry 或 Mapper 让领域对象重新依赖外部记录结构”。

先预测：旧 API 返回 snake_case 记录而新 API 返回嵌套 JSON，订单用例应该修改哪里？如果测试替身要替换真实网关，接口应该由谁定义？先写下端口、映射和失败边界，再阅读实现；验证时要能说明替换外部系统不会改变领域对象的金额和状态语义。

type OrderRecord = {
  order_id: string;
  total_cents: number;
  state: "open" | "paid";
};
 
type Order = {
  id: string;
  totalCents: number;
  state: "open" | "paid";
};
 
interface OrderGateway {
  find(orderId: string): Promise<OrderRecord | null>;
}
 
class OrderMapper {
  toDomain(record: OrderRecord): Order {
    return {
      id: record.order_id,
      totalCents: record.total_cents,
      state: record.state,
    };
  }
}
 
class FindOrder {
  constructor(
    private readonly gateway: OrderGateway,
    private readonly mapper: OrderMapper,
  ) {}
 
  async execute(orderId: string): Promise<Order | null> {
    const record = await this.gateway.find(orderId);
    return record ? this.mapper.toDomain(record) : null;
  }
}

这里由 Separated Interface 让用例依赖 OrderGateway，由 Gateway 封装外部访问，由 Mapper 把记录转换为领域对象。替换旧 API 时只需要更换 Gateway 实现和必要的映射测试；不要让领域层直接读取 order_id 或把外部 JSON 作为领域实体传递。

基本模式依赖关系

Gateway 封装访问，Mapper 翻译表示，Registry 提供可控的查找点，Layer Supertype 共享层内稳定规则，Separated Interface 控制接口的归属。图中的箭头不是“模式越多越好”，而是用来检查依赖方向是否仍然由调用者的语义驱动。

基本模式边界决策图

先问“哪条变化轴正在发生”，再问“边界是否能减少该变化的传播”。没有外部变化就不要加 Gateway，没有表示差异就不要加 Mapper，没有运行时发现需求就不要加 Registry；选择 Separated Interface 时要确保接口归使用者拥有。

选择与拒绝矩阵

常见误区

可验证练习

名词解释

本章小结

掌握第18章基本模式的标志不是记住五个构件名称，而是能在订单系统基础设施替换中解释“用例 → Separated Interface → Gateway → 外部记录 → Mapper → 领域对象”的责任链。学习者应利用依赖方向、对象语义、配置、测试隔离和表示转换作出可证伪的选择，并在没有变化轴的间接层、万能 Mapper、全局 Registry 和跨层基类时明确拒绝当前实现。

前后导航

• 上一页：17.3 数据库会话状态
• 下一页：18.1 入口

来源与改写范围

• Martin Fowler 作者图书页：核对全书主题、教程与模式参考结构。
• Martin Fowler 模式目录：核对 Gateway、Mapper、Registry 与接口边界模式的公开摘要。
• Pearson 出版社页面：交叉核对英文版出版信息与目录范围。