9.3 表模块

为什么 9.3 表模块值得单独学习

表模块不是把每一行机械地包装成对象，而是用一个实例处理一组记录的业务逻辑，在记录集与面向对象行为之间取得集合式平衡。它适合规则围绕表或视图集合变化、但还没有足够理由为每一行建立完整领域对象的场景。

订单折扣与授信能暴露这个取舍。订单表模块可以集中处理折扣计算、授信校验和批量更新，让多个入口复用同一套集合规则；但如果每个订单都有复杂生命周期、不变量和跨对象协作，表模块的集合边界就可能遮住真正的领域边界。

边界必须能回答谁拥有筛选条件、谁保护集合不变量、谁开启事务，以及失败时哪些行应一起回退。

Row Set 是表模块每次操作的实际输入，必须带着筛选条件、版本和预期变更一起进入验证，不能只传一串没有语义的行号。

先建立直觉：集合责任要有明确所有者

事务脚本适合少量步骤和单一用例；当多个入口都要处理订单表的相同集合规则时，复制脚本会让折扣、额度和状态判断逐渐分叉。

领域模型适合复杂、频繁变化且需要对象协作的规则，但会引入对象边界和持久化映射成本。表模块位于两者之间：它集中一组记录的行为，却不承诺每一行都拥有完整对象身份。

先预测：如果订单查询、批量折扣和授信校验都读取同一张订单表，应该让控制器各写一遍条件，还是让 OrderTableModule 统一维护集合规则？判断依据不是类名，而是规则是否围绕同一记录集变化，以及事务能否把相关行作为一个一致性单元处理。

目录单元到教学证据

9.3 表模块

在 9.3 表模块 的单元边界内，学习者要把订单折扣与授信拆成查询、计算、校验和提交四类证据：哪些操作共享同一个集合边界，哪些规则只适用于单行，哪些变化需要对象协作。单元键为 poeaa24-pattern-03-table-module；核心证据是相同规则从两个入口调用时仍只有一个实现，并且失败能定位到事务中的首个差异。

评审记录还要回答：表模块实例拥有哪张表或视图，集合筛选条件是否稳定，批量操作的事务范围是什么，数据库约束与代码规则如何分工，什么时候应迁移到领域模型。如果只能说“ORM 有一个模块类”，却说不出这些边界，模式选择还没有完成。

专属代码案例：订单折扣与授信

下面的代码把订单表模块的责任固定为集合操作。它不模拟 ORM API，而是刻意让评审看到：同一实例负责加载订单、应用折扣、校验额度和提交结果；调用者不能绕过模块直接改写中间状态。

type OrderRow = {
  id: string;
  customerId: string;
  totalCents: number;
  discountCents: number;
  status: "pending" | "approved" | "rejected";
};
 
type CreditSnapshot = { availableCents: number };
 
class OrderTableModule {
  constructor(private readonly rows: OrderRow[]) {}
 
  approveBatch(ids: string[], credit: CreditSnapshot): OrderRow[] {
    const selected = this.rows.filter((row) => ids.includes(row.id));
    const required = selected.reduce(
      (sum, row) => sum + row.totalCents - row.discountCents,
      0,
    );
    if (required > credit.availableCents) {
      throw new Error("credit limit exceeded");
    }
    for (const row of selected) row.status = "approved";
    return selected;
  }
}

这段代码的最小证据合同是：选择条件由表模块拥有，批量总额计算集中在模块内，授信失败不会部分批准，成功状态只在校验通过后改变。生产实现还需把数据库事务、并发保护和消息投递接入同一张决策记录，不能把内存示例当成完整一致性保证。

模式结构图

模式结构图先显示调用方、表模块实例、记录集合与授信边界的责任流；它帮助评审区分“集合规则集中”与“所有业务都塞进一个大类”。

表模块的事务边界

一次批量批准应在读取快照、计算总额、校验额度和写回状态之间保持明确边界。若数据库更新与外部通知不在同一事务中，必须额外记录消息状态和补偿路径，不能把提交成功误认为所有副作用都已完成。

选择与拒绝矩阵

常见误区

可验证练习

名词解释

本章小结

掌握 9.3 表模块的标志，不是记住“一个类处理一张表”，而是能在订单折扣与授信中解释“选择记录 → 计算集合规则 → 校验额度 → 一致提交”的责任链。表模块应集中稳定的集合行为，事务脚本、领域模型和应用服务分别承担不同的变化与协调责任；当单行生命周期、跨聚合不变量或外部副作用成为主要变化轴时，应明确迁移和撤回条件。

前后导航

• 上一页：9.2 领域模型
• 下一页：9.4 服务层

来源与改写范围

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