Martin Fowler 的《企业应用架构模式》（Patterns of Enterprise Application Architecture, PoEAA）并非一本“设计模式手册”，而是一套面向复杂业务系统的架构决策框架。其核心价值在于：将混沌的业务需求，映射到可组合、可演进的技术结构。
一、根本目标：解决什么问题？
企业应用（如 ERP、银行系统）的典型挑战：
- 数据持久化：对象 ↔ 关系数据库的阻抗失配
- 业务逻辑分散：逻辑散落在 UI、SQL、脚本中
- 事务一致性：跨表操作需原子性
- 演化成本高：改一处，崩全局
✅Fowler 的答案：
通过标准化模式，建立“业务语义”与“技术实现”的清晰契约。
二、模式分类体系（三层架构视角）
Fowler 将模式分为5 大类，覆盖从数据到表现层的全链路：
| 类别 | 核心问题 | 代表模式 |
|---|---|---|
| 1. 领域逻辑模式 | 如何组织业务规则？ | Transaction Script, Domain Model, Service Layer |
| 2. 数据源架构模式 | 如何同步内存对象与数据库？ | Table Data Gateway, Row Data Gateway, Active Record,Data Mapper |
| 3. 对象-关系元数据映射 | 如何自动化 ORM？ | Metadata Mapping, Query Object, Repository |
| 4. Web 表现层模式 | 如何解耦 UI 与逻辑？ | Front Controller, Page Controller, Transform View |
| 5. 分布式架构模式 | 如何跨进程通信？ | Remote Facade, Data Transfer Object (DTO) |
💡关键洞察：
这些模式不是“银弹”，而是“决策点”——每个选择带来特定权衡。
三、核心模式深度拆解
1.领域逻辑模式（如何写业务代码）
| 模式 | 适用场景 | PHP 示例 | 缺陷 |
|---|---|---|---|
| Transaction Script | 简单流程（无复杂状态） | Laravel Controller 直接调 Eloquent | 逻辑重复、难测试 |
| Domain Model | 复杂业务规则（如订单状态机） | 充血模型：$order->cancel() | 学习曲线陡峭 |
| Service Layer | 协调多个领域对象 | OrderService::create($items) | 易沦为贫血服务 |
✅PHP 现实：
90% 项目用Transaction Script（Laravel 默认），仅核心域用Domain Model。
2.数据源架构模式（如何访问数据库）
| 模式 | 特点 | PHP 实现 | 适用 |
|---|---|---|---|
| Active Record | 对象 = 行 + 行为 | Eloquent Model | CRUD 应用 |
| Data Mapper | 对象与 DB 完全分离 | Doctrine ORM | 复杂领域模型 |
| Table/Row Gateway | 过程式数据访问 | 自定义 DB Helper | 遗留系统改造 |
⚠️Fowler 原意：
Active Record 适合简单场景，Data Mapper 适合复杂领域——但 PHP 社区常滥用 AR。
3.Repository 模式（PoEAA 第 322 页）
- 本质：集合抽象（
$users->find(1)如操作内存数组） - 关键约束：
- 返回领域对象（非 DB 记录）
- 隐藏查询细节（业务层不应写 SQL）
- 与 DAO 区别：
DAO 是CRUD 接口，Repository 是聚合根行为接口
4.Service Layer（PoEAA 第 133 页）
- 目的：定义应用边界（Application Boundary）
- 特征：
- 方法 = 用例（
placeOrder()） - 协调 Domain Model + Repository + 事务
- 方法 = 用例（
- 反模式：
“Service” 仅转发 Repository 调用 →贫血层
四、模式间的协同与冲突
1.经典组合
2.致命冲突
- Active Record + Domain Model：
AR 将持久化逻辑混入领域对象，破坏封装性。 - Transaction Script + Repository：
TS 无需对象抽象，Repository 成冗余层。
💡Fowler 的忠告：
“模式必须成组使用，孤立采用必失败”。
五、对现代 PHP 开发的启示
1.Laravel 的隐含模式
- Eloquent = Active Record
→ 适合快速开发，但阻碍 Domain Model - Service Provider = Registry
→ 依赖注入容器的简化版 - Queues = Message Bus
→ 异步解耦的基础设施
2.何时需要升级架构？
| 信号 | 应引入模式 |
|---|---|
| 业务规则散落在 Controller | Domain Model + Service Layer |
| 多数据源（MySQL + MongoDB） | Repository + Data Mapper |
| 测试需启动数据库 | Repository（Mockable） |
3.避免过度设计
- CRUD 应用：坚持 Transaction Script + Active Record
- 核心域：逐步引入 Domain Model + Repository
✅务实原则：
用最简模式解决当前复杂度，而非预支未来。
六、常见误读与澄清
| 误读 | 真相 |
|---|---|
| “PoEAA 是 GoF 设计模式的扩展” | GoF 关注对象交互，PoEAA 关注系统架构 |
| “必须用所有模式” | 模式是工具箱，非** checklist** |
| “Repository 就是 DAO” | Repository 面向聚合行为，DAO 面向表操作 |
| “Service Layer = 所有业务逻辑” | Service Layer 应薄，核心逻辑在 Domain Model |
总结：PoEAA 的工程心法
- 模式是决策，不是装饰：
每个模式解决特定痛点，需明确“为什么用”。 - 分层是手段，解耦是目的：
领域层必须独立于框架、数据库、UI。 - 渐进式演进：
从 Transaction Script 开始，随复杂度增长引入 Domain Model。 - PHP 的现实路径：
Laravel 快速验证 → 核心域提取充血模型 → Repository 隔离数据源。
💡终极价值：
PoEAA 不是教你怎么写代码，而是教你如何思考系统结构。
当你能回答“我的订单取消逻辑，该放在 Controller、Service 还是 Order 对象中？”时，
你已掌握其精髓。
