分层架构

学习目标

• 能解释“分层架构”如何按用户交互、用例编排、领域规则和技术实现分配职责，并让领域模型免受外层机制污染
• 能逐项定位 用户界面层、应用层、领域层、基础设施层、分层依赖方向，并说明每个概念在当前来源边界内承担什么责任
• 能按 接收用户意图 → 编排应用任务 → 执行领域规则 → 调用技术端口 → 呈现用例结果 推演“修改计价规则”，检查“领域对象可以脱离用户界面和持久化技术表达业务规则，应用层只编排而不吞并领域知识”
• 能注入“把四个目录名当成文件夹后仍允许领域层直接调用 SQL、HTTP 与界面控件”，依据层职责表、跨层调用记录、领域单元测试、持久化替换实验与业务规则归属清单定位越界、撤销并用同一情境重放

为什么从“让每层只承担一种推理尺度，并以领域层能否独立运行作为分层是否真实的检验”开始

按用户交互、用例编排、领域规则和技术实现分配职责，并让领域模型免受外层机制污染。本页先画责任和依赖，再沿具体情境执行决策，最后主动制造一个边界违规；这种顺序把术语变成可以验证、推翻和恢复的设计合同。

“分层架构”不是技术采购建议。它处理的是规则放在哪里、模型在哪个语境内成立、哪些变化可以被隔离，以及团队如何判断一条边界已经被穿透。最终功能可运行，只能证明快乐路径存在，不能证明结构允许安全演进。

来源、版次与课程边界

分层架构的模式边界以 Evans 官方 DDD Reference 及其 CC 授权 PDF 摘要核对；Pearson 原书页只负责版次身份，本文示例不是原书译文。

本专题不是某一本既有书的中文版，也不是把多位作者的文章拼成“原著章节”。课程主干分别取自 Eric Evans 的领域驱动设计体系与 Robert C. Martin 的整洁架构体系；CQRS、事件溯源和六边形架构始终标为扩展。以下链接承担不同事实责任：

• Pearson: Domain-Driven Design：核对 Eric Evans、第一版、出版信息与原书身份，不据此声称拥有全文
• Eric Evans: Domain-Driven Design Reference：核对 DDD 定义、模式摘要、增补范围与 CC 授权说明
• Domain-Driven Design Reference PDF：核对分层、限界上下文、战术模式和上下文映射的公开摘要正文

本页采用独立中文重写。能从公开全文或授权摘要核对的定义才作为来源事实；项目情境、交互实验、取舍表和练习答案均为本站教学设计。

核心概念与可观察责任

用户界面层

解释用户请求并呈现结果，不决定核心业务规则；同一个应用用例可以由 Web、命令行或批处理入口触发。 在“修改计价规则”中，观察重点是领域对象可以脱离用户界面和持久化技术表达业务规则，应用层只编排而不吞并领域知识。

应用层

协调任务、事务与领域对象，保持很薄，不包含决定业务含义的规则；它描述一次用例如何完成。 在“更换入口”中，观察重点是层职责表、跨层调用记录、领域单元测试、持久化替换实验与业务规则归属清单。

领域层

承载业务概念、状态和规则，是模型驱动设计的核心；它不应为了某种数据库表示而改变自身语义。 在“修改计价规则”中，观察重点是领域对象可以脱离用户界面和持久化技术表达业务规则，应用层只编排而不吞并领域知识。

基础设施层

提供消息、持久化、文件和框架等通用技术能力，通过接口服务上层，而非把技术 API 推入领域模型。 在“更换入口”中，观察重点是层职责表、跨层调用记录、领域单元测试、持久化替换实验与业务规则归属清单。

分层依赖方向

上层调用下层不等于任意源码耦合；重要的是领域政策不依赖用户界面或基础设施的具体实现。 在“修改计价规则”中，观察重点是领域对象可以脱离用户界面和持久化技术表达业务规则，应用层只编排而不吞并领域知识。

一条可执行的设计判断

本页采用以下判断链：让每层只承担一种推理尺度，并以领域层能否独立运行作为分层是否真实的检验。正常情况下必须持续保持“领域对象可以脱离用户界面和持久化技术表达业务规则，应用层只编排而不吞并领域知识”；反例“把四个目录名当成文件夹后仍允许领域层直接调用 SQL、HTTP 与界面控件”只改变一个关键条件，便于定位因果。

观察项	本页合同
最小正常情境	阶梯折扣规则改变但数据库表结构不变
边界或迁移情境	把客服 Web 操作增加为夜间批处理任务
必须保持	领域对象可以脱离用户界面和持久化技术表达业务规则，应用层只编排而不吞并领域知识
首要违规	把四个目录名当成文件夹后仍允许领域层直接调用 SQL、HTTP 与界面控件
验收证据	层职责表、跨层调用记录、领域单元测试、持久化替换实验与业务规则归属清单

先预测，再操作三个本页实验

⚡分步1 / 3

1. 1
2. 2
3. 3

实验一：边界与模型地图

操作前先预测“修改计价规则”里哪一侧拥有规则、哪一侧只是技术或协作细节。切换概念和情境后，检查“让每层只承担一种推理尺度，并以领域层能否独立运行作为分层是否真实的检验”是否仍能解释三块区域的责任。

Boundary model

分层架构：边界与责任地图

按用户交互、用例编排、领域规则和技术实现分配职责，并让领域模型免受外层机制污染

切换最小情境

修改计价规则更换入口

定位正式概念

用户界面层应用层领域层基础设施层分层依赖方向

architecturedomaindesign-04 · 当前观察

用户界面层：阶梯折扣规则改变但数据库表结构不变

区域 1交互与编排

界面解释请求，应用层组织用例

↓

区域 2领域模型

表达业务含义、状态与规则

↓

区域 3技术服务

持久化、消息与框架实现

情境验收

规则修改集中在领域层，应用层只继续编排计价用例

上一步重置播放下一步

易错边界与取舍

练习与答案

练习

问题 1：概念—边界—证据对照。 完成以下逐项核对：

1. 用户界面层：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
2. 应用层：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
3. 领域层：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
4. 基础设施层：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。
5. 分层依赖方向：写出它所在的边界、允许的依赖方向、一个最小反例和一份可观察证据。

查看答案

对每个概念先确定它属于业务政策、模型协作还是外部技术，再画允许的依赖方向。用“阶梯折扣规则改变但数据库表结构不变”建立正常基线，用“把四个目录名当成文件夹后仍允许领域层直接调用 SQL、HTTP 与界面控件”作为单一反例，最后从层职责表、跨层调用记录、领域单元测试、持久化替换实验与业务规则归属清单中找第一处不一致。

问题 2：最小情境推演。 怎样验证“修改计价规则”没有靠最终功能碰巧通过？

查看答案

按 接收用户意图 → 编排应用任务 → 执行领域规则 → 调用技术端口 → 呈现用例结果 保存每步状态，预期结果是“规则修改集中在领域层，应用层只继续编排计价用例”。最终输出之外，还要逐步确认“领域对象可以脱离用户界面和持久化技术表达业务规则，应用层只编排而不吞并领域知识”；任一中间状态越界都应拒绝当前设计。

问题 3：替代方案与恢复。 注入“把四个目录名当成文件夹后仍允许领域层直接调用 SQL、HTTP 与界面控件”后，怎样比较修复与更简单方案？

查看答案

先保留故障前的层职责表、跨层调用记录、领域单元测试、持久化替换实验与业务规则归属清单，再记录首个越界位置。分别实施最小修复和删除多余模式的方案，用同一个“把客服 Web 操作增加为夜间批处理任务”重放；选择仍满足“新增界面入口，共用应用用例与领域模型”且依赖更少的方案。

本页小结

• 分层架构的核心判断是：让每层只承担一种推理尺度，并以领域层能否独立运行作为分层是否真实的检验。
• 正常路径以“规则修改集中在领域层，应用层只继续编排计价用例”验收，不能只检查接口返回成功。
• 边界路径以“新增界面入口，共用应用用例与领域模型”验收，并保存层职责表、跨层调用记录、领域单元测试、持久化替换实验与业务规则归属清单。
• 如果“把四个目录名当成文件夹后仍允许领域层直接调用 SQL、HTTP 与界面控件”仍可静默通过，说明边界只是图示，没有成为可执行约束。