第8章 通盘考虑

学习目标

• 能解释从领域层到数据源层再到表示层的完整请求路径中，每个模式解决什么问题
• 能根据业务复杂度判断哪些模式可以省略，哪些不可或缺
• 能对一道跨进程调用场景走完"领域选择→数据映射→表示入口→部署技术→替代分层"的判断链

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

先猜一猜：一个简单的博客系统和复杂的电商系统，在架构模式的选择上最大的区别是什么？是都用了同样的模式，还是电商需要更多的模式层？

通盘考虑面对的具体压力是"网络往返、载荷大小、超时比例、幂等键与兼容版本"。它采用的机制可以概括为：从领域层开始贯通数据源与表示层，并按问题复杂度和技术条件组合模式。机制带来的收益必须与新增间接层、同步责任或迁移成本同时记录，否则学习者只会得到一个没有拒绝条件的模式名称。

对 第8章 通盘考虑，优先比较的替代路线是：能保持本地调用时不分布；必须跨进程时组合远程外观与数据传输对象。本页的通过条件是"能解释通盘考虑的边界与选择轴，逐项覆盖5个目录节点，并在同一应用切片中验证"；若实验只能显示结果而不能指出 模式组合从何处越界，就不能据此选择 第8章 通盘考虑。

目录单元到教学证据

8.1 从领域层开始

所有架构决定都从领域层开始。领域层是业务规则的核心，它的设计决定了上层（表示层）和下层（数据源层）的接口契约。领域层的选择直接影响整个系统的复杂度：简单业务可以用事务脚本，复杂业务需要领域模型，而选择哪个决定了后续数据源和表示层的模式组合。

8.2 深入到数据源层

领域层确定后，下一步是选择数据源模式。如果领域层用了事务脚本，表数据入口是最自然的配合；如果用了领域模型，数据映射器或行数据入口更合适。数据源层的选择不仅要考虑领域层的需求，还要考虑查询性能、并发控制和事务边界。

8.3 表示层

表示层是用户与系统的交互界面。它不包含业务逻辑，只负责展示和转发。表示层的模式选择（MVC、页面控制器、前端控制器、模板视图等）取决于交互复杂度和部署方式。简单页面用页面控制器，复杂交互用前端控制器+模板视图组合。

8.4 一些关于具体技术的建议

在实际项目中，技术选型会受到现有基础设施、团队技能和部署环境的约束。例如，使用 Java 还是 .NET 会影响可用的 ORM 框架和事务管理方式。关键原则是：让技术适应架构，而不是让架构迁就技术。

8.5 其他分层方式

三层架构不是唯一的分层方式。六边形架构、CQRS、事件驱动架构等提供了不同的关注点分离方式。选择哪种分层方式取决于问题的性质：领域逻辑复杂选六边形，读写不对称选 CQRS，异步协作选事件驱动。

全景组装：模式如何协作

前七章分别讲了分层、领域逻辑、映射、表示、并发、会话和分布。本章把它们组装成一条完整的请求路径——每个模式解决层间的一个具体问题。

⚡分步1 / 3

1. 1
2. 2
3. 3

重置

本地调用的简化路径

对于简单应用（如博客系统），请求路径可以简化：表示层（Page Controller）→ 领域层（Transaction Script）→ 数据源层（Table Data Gateway）。不需要 Service Layer、Unit of Work 或 Data Mapper 等额外模式。

上一步播放下一步

常见误区

专属设计案例：订单与结算跨进程调用

把 订单与结算跨进程调用 切成"领域选择 → 数据映射 → 表示入口 → 部署技术 → 替代分层"五个观察点。第8章 通盘考虑 的设计草案必须写出谁拥有状态、谁作出业务决定、失败怎样传播，以及 模式组合、领域起点、数据源、表示层、技术约束 中哪个指标最先提示当前方案不再适用。

设计记录采用五个可换行字段：单元键为 poeaa24-chapter-08-putting-together；模式族为 distribution；裁决是"能解释通盘考虑的边界与选择轴，逐项覆盖5个目录节点，并在同一应用切片中验证"；观测项包括 模式组合、领域起点、数据源、表示层、技术约束；拒绝条件是"模式组合 超过团队为 第8章 通盘考虑 设定的边界"。

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

选择与拒绝矩阵

评审问题	选择 第8章 通盘考虑 的证据	应拒绝或改用其他方案的信号
责任	领域选择 到 替代分层 的所有者清晰	数据映射 可以绕过边界直接改写状态
变化	模式组合 的变化被局部吸收	一次小改动同时触及 领域起点、数据源、表示层
失败	故障能在 替代分层 前被识别并回退	只能看到最终错误，无法定位 模式组合 的首个异常
替代	已与同族候选比较并保留撤回路径	因框架内置或团队习惯而跳过问题分析

本章小结

1. 所有架构决定从领域层开始，领域层的设计决定了数据源和表示层的模式组合。
2. 跨进程调用必须使用粗粒度接口（Remote Facade + DTO）减少网络往返。
3. 模式选择遵循最小必要集原则：复杂应用每一层都不可或缺，简单应用可以跳过很多层。
4. 三层架构不是唯一的分层方式，六边形架构、CQRS、事件驱动等提供了不同的选择。
5. 选择与拒绝矩阵帮助你在真实项目中判断模式组合是否合适。

本章练习

练习

问题 1： 一个简单的博客系统只需要发布文章和展示文章列表。应该选择哪些模式层？哪些模式层可以省略？

查看答案

最小必要集：表示层用 Page Controller + Template View 处理页面展示，领域层用 Transaction Script 处理发布和查询逻辑，数据源层用 Table Data Gateway 读写数据库。可以省略的模式层：Service Layer（不需要事务边界）、Unit of Work（不需要跟踪变更集）、Data Mapper（不需要复杂对象关系映射）、Identity Map（不需要跨多次加载保证同一实例）。

问题 2： 一个订单系统需要跨进程调用结算服务。调用方应该使用什么接口风格？为什么？

查看答案

应该使用粗粒度接口（Remote Facade），每个远程调用完成一个完整的业务操作，如 SubmitOrder(orderId) 而不是多个细粒度调用如 setItem()、applyDiscount()、calculateTotal() 等。原因：1）减少网络往返次数，每次调用都有延迟开销；2）粗粒度接口可以封装事务边界，确保业务操作要么全部成功要么全部回滚；3）避免领域对象内部结构暴露给远程调用方。

问题 3： 团队说"我们用三层架构，所以必须把表示层、领域层、数据源层部署到三台不同的服务器上"。如何用选择与拒绝矩阵来评估这个决定？

查看答案

分别检查四个评审问题：责任—谁负责决定部署方式？变化—如果业务需求变化，三层部署能否灵活调整？失败—网络故障时，跨服务器部署的故障隔离是否有效？替代—是否与单体部署、微服务等替代方案比较过？如果只因为"三层架构"就默认需要三台服务器，应拒绝当前方案。逻辑分层不等于物理部署，应该先根据延迟、扩缩容和安全要求评估是否需要分进程。

出处声明

名词解释

名词解释

本章出现的专业名词，用大白话再讲一遍。

通盘考虑

从领域层开始贯通数据源与表示层，按问题复杂度和技术条件组合模式的架构决策方法。

模式组合

在同一个架构中组合使用多个模式，每个模式解决层间的一个具体问题，形成完整的请求路径。

领域层

封装业务规则和逻辑的核心层，是所有架构决定的起点。

数据源层

负责与数据库或外部系统通信，提供数据持久化和检索能力，配合领域层选择适当的映射模式。

表示层

负责用户交互和界面展示，接收用户输入并转发给领域层，不含业务逻辑。