为什么 13.3 资源库 值得单独学习

在领域与数据映射层之间提供类似集合的接口，集中表达领域对象的获取和保存意图。13.3 资源库的核心不是套用某个框架 API，而是回答：如何让领域服务用业务语言表达获取聚合，同时不暴露 SQL、ORM 和映射生命周期。在订单聚合持久化中，如果无法说清责任、状态和失败由谁承担，即使正常请求能够返回，架构决定也没有完成。

的价值不是把每条查询都包一层，而是让持久化细节服从聚合边界和领域语言。本页以 2024 年中文版公开目录限定 13.3 资源库 的范围，并依据 Martin Fowler 的作者图书页和模式目录独立重写。它不复现原书正文、插图或代码；目录只决定“要讲什么”，这里的案例、实验、判断题和答案均为本课程原创。

先建立直觉：问题、机制与代价

13.3 资源库面对的具体压力是“聚合身份、查询组合、事务协作、映射替换和测试隔离”。它采用的机制可以概括为：领域层依赖集合式接口，具体实现协调 Mapper、缓存和工作单元。机制带来的收益必须与新增抽象、查询泄漏和接口膨胀成本同时记录，否则学习者只会得到一个没有拒绝条件的模式名称。

对 13.3 资源库，优先比较的替代路线是：直接查询服务、专用查询对象、数据访问对象或活动记录。只有在需要围绕聚合根统一获取、保存和事务语义时，才值得引入资源库；若资源库只是把每个 SQL 原样转发，或者接口暴露了数据库行，就应拒绝当前设计。聚合根决定资源库的粒度，而不是表的数量。

目录单元到教学证据

13.3 资源库

在 13.3 资源库 的学习边界里，13.3 资源库不是待背诵的目录词，而是用来检查“领域意图”是否把持久化责任交给正确对象。对订单聚合持久化，学习者要记录查询语言、事务归属和映射细节的可观察变化，并说明它何时支持或否定 13.3 资源库。

专属设计案例：订单聚合持久化

把订单聚合持久化切成“领域意图 → 资源库接口 → 映射实现 → 数据源 → 聚合结果”五个观察点。13.3 资源库的设计草案必须写出谁拥有状态、谁作出业务决定、失败怎样传播，以及元数据校验、查询组合、资源库边界、参数化、类型恢复中哪个指标最先提示当前方案不再适用。

设计记录采用五个可换行字段：单元键为 poeaa24-pattern-24-repository；模式族为 mapping；裁决是“能让领域服务使用领域词汇查询聚合，证明资源库没有承载业务规则或返回持久化细节”；观测项包括元数据校验、查询组合、资源库边界、参数化、类型恢复；拒绝条件是“资源库接口暴露表结构，或无法说明聚合事务边界”。

配置不是生产框架语法，而是一张评审卡。对 13.3 资源库的任何实现都要能把运行证据重新映射到这张卡；如果更换 ORM、Web 框架或部署平台后无法回答同一组问题，说明决定依赖的是工具偶然行为而不是模式语义。

结构解剖

选择与拒绝矩阵

代码实践：用集合式接口隔离订单持久化

领域服务只依赖 OrderRepository，而内存实现可以在测试中替换真实数据库。领域查询意图应保持小而稳定；复杂报表可走专用查询对象，不必硬塞进聚合资源库。

type Order = {
  id: string;
  status: "open" | "paid" | "cancelled";
  totalCents: number;
};
 
interface OrderRepository {
  findById(id: string): Order | undefined;
  findByStatus(status: Order["status"]): Order[];
  save(order: Order): void;
}
 
class InMemoryOrderRepository implements OrderRepository {
  constructor(private readonly orders: Order[] = []) {}
 
  findById(id: string): Order | undefined {
    return this.orders.find((order) => order.id === id);
  }
 
  findByStatus(status: Order["status"]): Order[] {
    return this.orders.filter((order) => order.status === status);
  }
 
  save(order: Order): void {
    const index = this.orders.findIndex(
      (candidate) => candidate.id === order.id,
    );
    if (index === -1) this.orders.push(order);
    else this.orders[index] = order;
  }
}
 
function markPaid(repository: OrderRepository, id: string): void {
  const order = repository.findById(id);
  if (!order) throw new Error("order not found");
  repository.save({ ...order, status: "paid" });
}

这段代码让业务用 findById 和 save 表达聚合意图，测试可以注入内存实现。生产实现可以协调 Mapper 与事务，但不应把 SQL、ORM 查询对象或数据库行类型放进 OrderRepository 接口。

常见误区

可验证练习

名词解释

本章小结

掌握 13.3 资源库的标志不是记住定义，而是能在订单聚合持久化中解释“领域意图 → 资源库接口 → 映射实现 → 数据源 → 聚合结果”的责任链，利用元数据校验、查询组合、资源库边界、参数化、类型恢复作出可证伪的选择，并在接口泄漏表结构或资源库承载业务规则时明确拒绝。

前后导航

• 上一页：13.2 查询对象
• 下一页：第14章 Web表现模式

来源与改写范围

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