第9章 领域逻辑模式
用四种领域组织方式匹配业务复杂度和应用边界。
学习目标
- 能比较事务脚本、领域模型、表模块与服务层各自承担的领域逻辑责任
- 能依据规则复杂度、对象协作和事务边界，为订单折扣场景选择可维护的组织方式
- 能识别业务规则泄漏到控制器或数据访问层的信号，并提出迁移方案
为什么 第9章 领域逻辑模式 值得单独学习
用四种领域组织方式匹配业务复杂度和应用边界。↡的核心不是套用某个框架 API，而是回答：如何让业务规则落在可演化的责任边界中，并与用例编排及持久化机制分离。在 订单折扣与授信 中，如果无法说清责任、状态和失败由谁承担，即使正常请求能够返回，架构决定也没有完成。
本页以 2024 年中文版公开目录限定 第9章 领域逻辑模式 的范围，并依据 Martin Fowler 的作者图书页和模式目录独立重写。它不复现原书正文、插图或代码；目录只决定“要讲什么”，这里的案例、实验、判断题和答案均为本课程原创。
先建立直觉：问题、机制与代价
第9章 领域逻辑模式 面对的具体压力是“规则分支、跨对象不变量、用例复用与事务范围”。它采用的机制可以概括为：用四种领域组织方式匹配业务复杂度和应用边界。↡带来的收益必须与新增间接层、同步责任或迁移成本同时记录，否则学习者只会得到一个没有拒绝条件的模式名称。
先猜一猜：一个只有两条折扣规则的订单服务，应该先建立对象模型，还是先写一个清晰的用例过程？答案取决于规则的变化方式，而不是团队已经使用的框架。
对 第9章 领域逻辑模式，优先比较的替代路线是：在 ↡、↡、↡和 ↡之间按复杂度与变化轴选择。本页的通过条件是“能解释领域逻辑模式的边界与选择轴，逐项覆盖4个目录节点，并在同一应用切片中验证”；若实验只能显示结果而不能指出规则复杂度从何处越界，就不能据此选择 第9章 领域逻辑模式。
目录单元到教学证据
第9章 领域逻辑模式
在 第9章 领域逻辑模式 的学习边界里，第9章 领域逻辑模式 不是待背诵的目录词，而是用来检查“请求”是否把责任交给正确对象。对 订单折扣与授信，学习者要记录 规则复杂度 的可观察变化，并说明它何时支持或否定 第9章 领域逻辑模式。
专属设计案例：订单折扣与授信
把 订单折扣与授信 切成“请求 → 业务规则 → 领域组织 → 事务 → 结果”五个观察点。第9章 领域逻辑模式 的设计草案必须写出谁拥有状态、谁作出业务决定、失败怎样传播，以及 规则复杂度、对象协作、表结构、服务边界、演化成本 中哪个指标最先提示当前方案不再适用。
设计记录采用五个可换行字段：单元键为 poeaa24-chapter-09-domain-logic-patterns；模式族为 domain；裁决是“能解释领域逻辑模式的边界与选择轴，逐项覆盖4个目录节点，并在同一应用切片中验证”；观测项包括 规则复杂度、对象协作、表结构、服务边界、演化成本；拒绝条件是“规则复杂度 超过团队为 第9章 领域逻辑模式 设定的边界”。
配置不是生产框架语法，而是一张评审卡。对 第9章 领域逻辑模式 的任何实现都要能把运行证据重新映射到这张卡；如果更换 ORM、Web 框架或部署平台后无法回答同一组问题，说明决定依赖的是工具偶然行为而不是模式语义。
模式族地图
阅读路径：规则少且结构化 → Table Module；规则少且自由 → Transaction Script；规则复杂 → Domain Model；任何复杂度都需要应用入口 → Service Layer。
用订单折扣走一遍选择过程
先写出一个用例的完整规则
先预测：当折扣只依赖订单金额且规则很少时，能否用一个过程把读取、计算和保存都交代清楚？若能，事务脚本让责任链最短，也最容易测试。
常见误区
选择与拒绝矩阵
| 评审问题 | 选择 第9章 领域逻辑模式 的证据 | 应拒绝或改用其他方案的信号 |
|---|---|---|
| 责任 | 请求 到 结果 的所有者清晰 | 业务规则 可以绕过边界直接改写状态 |
| 变化 | 规则复杂度 的变化被局部吸收 | 一次小改动同时触及 对象协作、表结构、服务边界 |
| 失败 | 故障能在 结果 前被识别并回退 | 只能看到最终错误，无法定位 规则复杂度 的首个异常 |
| 替代 | 已与同族候选比较并保留撤回路径 | 因框架内置或团队习惯而跳过问题分析 |
本章小结
掌握 第9章 领域逻辑模式 的标志不是记住定义，而是能在 订单折扣与授信 中解释“请求 → 业务规则 → 领域组织 → 事务 → 结果”的责任链，利用 规则复杂度、对象协作、表结构、服务边界、演化成本 作出可证伪的选择，并在出现“把所有规则塞进控制器或服务层过程”时明确拒绝当前实现。
本章练习
练习
问题 1： 一个订单服务只有“满 100 减 10”和“新用户首单减 5”两条稳定规则。选事务脚本还是领域模型？写出判断依据。
问题 2： 会员等级、授信额度和促销互斥条件开始共同影响下单结果，且这些规则被退款和改价用例复用。下一步应如何调整？
问题 3： 团队把所有折扣计算都写在 Service Layer 中，并称它“统一了业务逻辑”。如何评审这个决定？
前后导航
出处声明
名词解释
名词解释
本章出现的专业名词，用大白话再讲一遍。
- 领域逻辑
- 体现业务规则、业务状态与不变量的决策部分；它应独立于 HTTP 入口和持久化细节。
- 事务边界
- 一个业务操作必须整体成功或整体失败的范围，通常由服务层协调，但不等同于具体业务规则。
- 事务脚本
- 以一个业务用例为单位组织逻辑的过程式模式，适合规则少、流程线性的场景。
- 领域模型
- 用对象及其协作表达复杂业务规则和不变量的模式，适合规则频繁变化或跨对象协作的场景。
- 表模块
- 以一张数据库表或记录集为中心组织业务逻辑的模式，适合结构化数据操作占主导的场景。
- 服务层
- 定义应用用例边界并协调事务、权限和多个领域对象的应用入口，不应复制领域规则。