分层架构

分层架构是所有软件架构的基础模型，是"稳定核心 + 可替换实现"的结构化设计方式。无论是 DDD、六边形架构、整洁架构，都可视为分层架构的演进形态。

本质：稳定性梯度（Stability Gradient）

系统内部存在不同变化速度的模块，分层即是：

按变化速度分区，把稳定的放核心，把易变的放边缘

稳定性从高到低示意：

Domain（本质规则）   ← 最稳定Application（用例编排）Presentation（交互协议）Infrastructure（技术细节） ← 最易变

分层的目标（而非手段）

目标解释
关注点分离每层只关心本层的问题，不跨层思考
隔离变化外部变化（协议、技术栈）不影响核心业务
建立清晰边界结构化组织业务、技术、协作
提升可测试性纯业务逻辑可独立测试
提升可演进性基础设施可替换（DB/Cache/消息中间件）

分层的黄金原则（核心规则）

（1）依赖倒置原则 DIP

（2）依赖单向流动（Unidirectional Dependency）

Presentation → Application → Domain → Infrastructure（接口）Infrastructure 实现 Domain 所定义的接口

（3）稳定性递增（Stability Increasing Toward Center）

越往内层越稳定，越难变化。

分层架构元模型（Meta Model）

这是本文最核心的抽象。

下面是一个标准 Layered Architecture 模型：

┌────────────────────────────┐│        Presentation          │  ← 输入协议（API/GUI/消息）└────────────────────────────┘┌────────────────────────────┐│        Application          │  ← 用例编排/事务管理/流程控制└────────────────────────────┘┌────────────────────────────┐│          Domain             │  ← 业务本质（实体/值对象/规则/策略）└────────────────────────────┘┌────────────────────────────┐│       Infrastructure        │  ← DB/Cache/MQ/HTTP/Config 实现└────────────────────────────┘

各层职责、输入、输出

层核心职责输入输出
Presentation协议适配、参数校验、序列化HTTP/GRPC/消息DTO
Application编排业务用例、事务、流程DTOCommand / Domain Model
Domain业务规则、实体、策略、限制CommandResult / Event
Infrastructure技术细节实现Repository 接口调用Data

如何判断"是否越界"？

越界访问例子（❌）：

越界属于"架构腐化"的主要原因之一。

为何分层（价值体系）

降低复杂度

每层只关注自己的抽象，不关注细节。

隔离变化

提高扩展性

可测试性提升

分层架构的常见问题 & 反模式

❌ 层次过多，导致性能差

反例：

改进：按变化速度，而非物理层数进行分层。

❌ Application 层过度膨胀

原因：

改进：将业务规则下沉到 Domain。

❌ 基础设施反向依赖领域

例如 Domain 依赖 Spring、Redis、MySQL、MQ 等。

改进：Infrastructure 依赖 Domain，不允许反向依赖。

❌ 缺乏边界限制

没有静态规则约束，导致循环依赖、跨层访问。

改进：使用 ArchUnit/Sonar 构建架构治理规则。

分层架构的模型扩展

分层架构与现代架构的关系

模型核心思想与分层关系
六边形架构端口-适配器分层的强抽象版
整洁架构同心圆稳定性分层进阶
DDD 分层架构领域中心化分层+业务建模

本质：都是分层思想的递进。

MVC / MVP / MVVM 属于"表示层内部模式"

需强调：

❗它们不是系统分层架构

MVC/MVP/MVVM 解决的是"表示层内部职责分离"，属于 Presentation 层子模式。

架构选型指南（极重要）

场景是否建议分层原因
中小型后台系统✓ 强烈建议可维护性高
中台/核心业务系统✓ 必须Domain 稳定层非常关键
高性能网关✗ 不建议复杂分层延迟敏感
简单 CRUD API△ 轻量分层即可避免过度工程化
微服务✓ 建议两层（Application+Domain）简化内部结构

分层架构的治理体系（落地关键）

依赖扫描

边界规范

测试矩阵

层测试方式
PresentationAPI 测试
Application集成测试
Domain纯单测
InfrastructureMock 测试

分层架构的演进路线（架构认知的核心）

三层架构（Controller-Service-DAO）        ↓ 识别贫血模型问题分层架构（Presentation-App-Domain-Infra）        ↓ 技术/业务解耦DDD 分层架构（Domain 强化）        ↓ 接口化驱动六边形架构 / 整洁架构（端口驱动）        ↓ 云原生多端协作 / 无服务化架构（BFF + 边缘层）

你可以看出：所有现代架构都是分层架构的加强版，而非替代方案。

完整对照示例（传统 vs 现代）

传统三层架构

Controller → Service → DAO → DB

现代分层架构

Controller   ↓Application（用例编排）   ↓Domain（业务规则、实体）   ↓Infrastructure（DB、MQ、Cache 具体实现）

优势：

总结

分层架构本质是把"稳定的业务本质"与"易变的技术细节"分开，使系统能够长期保持可维护、可演进，并能以最小代价适应前端、协议、技术栈的变化。

关联内容（自动生成）