第1章 分层

学习目标

• 能解释表示层、领域层、数据源层三层各自的职责和依赖方向
• 能区分逻辑分层与物理部署，说明什么情况下三层可以合并到同一进程
• 能对一道架构设计场景走完"请求→表示层→领域层→数据源层→运行环境"的判断链

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

先猜一猜：一个电商系统的订单提交功能，用户点击"提交"后，请求经过哪些环节才能到达数据库？这些环节应该按什么顺序组织？

分层 面对的具体压力是"跨层调用、依赖方向、部署节点与错误翻译位置"。它采用的机制可以概括为：从职责和依赖方向建立表示、领域、数据源三层，决定物理部署而不把层与进程混同。机制带来的收益必须与新增间接层、同步责任或迁移成本同时记录，否则学习者只会得到一个没有拒绝条件的模式名称。

对 第1章 分层，优先比较的替代路线是：先划职责和依赖，再根据延迟、扩缩容与安全要求决定是否分进程。本页的通过条件是"能解释分层的边界与选择轴，逐项覆盖3个目录节点，并在同一应用切片中验证"；若实验只能显示结果而不能指出 职责边界 从何处越界，就不能据此选择 第1章 分层。

三层架构解剖

分层的核心是把职责沿依赖方向切成三层，每层只与相邻层通信，上层依赖下层，禁止反向依赖。

1.1 企业应用中层次的演化

表示层负责用户交互和界面展示，是系统的入口。它接收用户输入，将请求转发给领域层，并将结果渲染给用户。表示层不包含业务逻辑——如果发现"这个按钮把金额乘以税率"的逻辑写在表示层，说明职责放错了位置。表示层的变化通常由 UI 需求驱动，不应影响领域层。

1.2 三个基本层次

领域层是系统的核心，封装所有业务规则和逻辑。它不关心数据如何存储，也不关心用户界面如何展示。领域层定义了业务概念、实体、值对象和领域服务。例如"订单总额计算""库存锁定""权限校验"都属于领域层的职责。领域层的变化由业务需求驱动，是最稳定的层。

1.3 为各层选择运行环境

数据源层负责与数据库、外部系统或消息队列通信。它提供数据的持久化和检索能力，将关系型数据映射为领域对象。依赖方向是分层的核心原则：表示层依赖领域层，领域层依赖数据源层，数据源层依赖数据库。禁止反向依赖，否则分层就失去了意义。

⚡分步1 / 3

1. 1
2. 2
3. 3

重置

表示层：交互与展示

上一步播放下一步

层到部署位置的映射

逻辑分层不等于物理分离。三层可以合并到同一进程（单体），也可以拆分到不同服务器（经典部署），甚至进一步拆成微服务：

选择部署方式时，不要把"逻辑层"和"进程/服务器"混为一谈。分层是设计决策，部署是运维决策——两者独立但相互约束。

常见误区

专属设计案例：订单审批分层

把 订单审批分层 切成"请求 → 表示层 → 领域层 → 数据源层 → 运行环境"五个观察点。第1章 分层 的设计草案必须写出谁拥有状态、谁作出业务决定、失败怎样传播，以及 职责边界、依赖方向、层间契约、部署位置、变更触达 中哪个指标最先提示当前方案不再适用。

设计记录采用五个可换行字段：单元键为 poeaa24-chapter-01-layering；模式族为 layering；裁决是"能解释分层的边界与选择轴，逐项覆盖3个目录节点，并在同一应用切片中验证"；观测项包括 职责边界、依赖方向、层间契约、部署位置、变更触达；拒绝条件是"职责边界 超过团队为 第1章 分层 设定的边界"。

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

选择与拒绝矩阵

评审问题	选择 第1章 分层 的证据	应拒绝或改用其他方案的信号
责任	请求 到 运行环境 的所有者清晰	表示层 可以绕过边界直接改写状态
变化	职责边界 的变化被局部吸收	一次小改动同时触及 依赖方向、层间契约、部署位置
失败	故障能在 运行环境 前被识别并回退	只能看到最终错误，无法定位 职责边界 的首个异常
替代	已与同族候选比较并保留撤回路径	因框架内置或团队习惯而跳过问题分析

本章小结

1. 三层架构的核心职责：表示层处理交互，领域层封装业务规则，数据源层负责持久化。
2. 依赖方向是分层的核心原则：上层依赖下层，禁止反向依赖。
3. 逻辑分层不等于物理部署——分层是设计决策，部署是运维决策。
4. 每层只与相邻层通信，绕过相邻层会破坏层的封装。
5. 选择与拒绝矩阵帮助你在真实项目中判断分层方案是否合适。

本章练习

练习

问题 1： 在一个订单系统中，"计算订单总价"和"将订单数据保存到数据库"分别属于哪个层的职责？

查看答案

"计算订单总价"属于领域层，因为它封装了业务规则（总价 = 单价 × 数量 × 折扣率×税率等）。"将订单数据保存到数据库"属于数据源层，因为它负责持久化。如果"计算订单总价"的逻辑出现在表示层（如前端 JavaScript 中直接计算），说明职责放错了位置，业务规则无法被统一管理和测试。

问题 2： 一个团队决定把三层拆成三个独立的进程部署。这样做的好处和代价分别是什么？

查看答案

好处：每一层可以独立扩缩容（如表示层需要更多实例应对流量高峰）、独立部署（修复数据源层bug不会影响领域层）、可以使用不同的技术栈。代价：增加了网络延迟（原来同一进程中的方法调用变成了远程调用）、需要处理分布式事务和故障（网络不可靠）、部署和运维复杂度上升。只有当延迟、扩缩容或安全的收益超过代价时，才应该拆成独立进程。

问题 3： 团队说"我们的表示层可以直接调用数据源层，因为这样更快"。如何用选择与拒绝矩阵来评估这个决定？

查看答案

分别检查四个评审问题：责任—跳过领域层后，谁负责执行业务规则？变化—业务规则变化时，跳过领域层的调用点是否需要逐个修改？失败—如果数据源层返回了错误数据，领域层的校验逻辑在哪里执行？替代—是否与分层架构的替代方案（如六边形架构、CQRS）比较过？如果只因为"更快"就跳过领域层，应拒绝当前方案。

出处声明

名词解释

名词解释

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

分层

将系统按职责切分为表示层、领域层和数据源层，上层依赖下层，禁止反向依赖，实现关注点分离。

表示层

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

领域层

封装业务规则和逻辑的核心层，定义业务概念、实体、值对象和领域服务。

数据源层

负责与数据库、外部系统或消息队列通信，提供数据持久化和检索能力。

依赖方向

分层架构的核心原则：表示层依赖领域层，领域层依赖数据源层，禁止反向依赖。