写后端写了一段时间后，很多人都会产生一个困惑：
👉 到底什么是“后端架构”？
👉 MVC 是不是后端架构？
👉 三层、DDD、洋葱、六边形到底是什么关系？名词越来越多，但项目结构却越来越乱。
这篇文章，我尝试用工程视角，把这些常见“后端架构叫法”和“真实工程分层边界”一次性对齐。
一、先给结论：后端不是 MVP / MVVM
在后端领域，几乎不使用 MVP / MVVM。
因为：
- 后端没有 UI
- 没有界面状态
- 不存在视图绑定
👉 MVP / MVVM 本质是UI 架构，解决的是界面复杂度问题。
后端真正要解决的是：
- 业务复杂度
- 系统可演进性
- 模块边界
- 依赖方向
- 基础设施隔离
所以，后端真正的主流架构，本质是：
👉分层架构 + 依赖控制 + 领域建模
二、后端真正稳定的“四层结构”
不管你听到的是 MVC、三层、DDD、洋葱、六边形，
几乎所有成熟后端系统，都可以抽象成下面这四层：
┌──────────────────────────┐ │ Interface / API 层 │ 接口与协议适配 ├──────────────────────────┤ │ Application 层 │ 业务流程编排 ├──────────────────────────┤ │ Domain 层 │ 业务核心模型 ├──────────────────────────┤ │ Infrastructure 层 │ 基础设施实现 └──────────────────────────┘这是工程级后端结构的“底座”。
三、每一层到底负责什么？
1️⃣ Interface / API 层（表现层、适配层）
典型形式：
- Controller
- Web / RPC / MQ 接口
职责只有一件事：
👉适配外部世界
包括：
- 接 HTTP / RPC / MQ
- 参数校验
- DTO / VO 转换
- 返回统一响应
不该做的事：
❌ 不写业务规则
❌ 不写 SQL
❌ 不做复杂事务
❌ 不做流程编排
这是很多项目最容易“写脏”的一层。
2️⃣ Application 层（应用层 / Service 层）
这是后端系统的调度中枢。
它关心的是：
👉系统如何运转
典型职责：
- 业务流程编排
- 跨聚合操作
- 事务边界
- 权限 / 幂等 / 一致性控制
- 调用多个 Domain / Repository / 外部系统
但它不应该沉淀核心业务规则。
Application 层更像：
👉 “用例调度器 / 流程引擎”
3️⃣ Domain 层（领域层 / 核心层）
这是后端系统最重要的一层。
它关心的是：
👉系统是什么
包含：
- 领域实体（Entity）
- 值对象（VO）
- 聚合根（Aggregate）
- 业务不变量
- 领域服务（Domain Service）
特点是：
- 不依赖数据库
- 不依赖 Spring
- 不关心 HTTP
- 可纯 Java 单测
👉 这里放的是：业务真理，而不是技术细节。
4️⃣ Infrastructure 层（基础设施层）
这是“系统如何落地”的地方：
- 数据库访问
- Redis
- MQ
- 第三方系统
- ORM / DAO
- 各种 Client
典型形式：
- Repository 实现
- Mapper / DAO
- 外部系统适配
它服务于 Domain 和 Application，
而不是反过来控制业务。
四、常见架构名词对照表
| 名词 | 它在强调什么 | 工程本质 |
|---|---|---|
| MVC | Web 请求分层 | Interface + Model（弱化View） |
| 三层架构 | 工程落地结构 | Controller / Service / DAO |
| DDD | 业务建模方法 | Domain 层变厚 |
| 洋葱架构 | 依赖方向 | 依赖只能向内 |
| 六边形架构 | 边界与适配 | 多入口、多出口 |
| Clean Architecture | 完整依赖规则 | 同构分层模型 |
👉 这些不是互斥架构，
👉 而是同一套结构的不同观察角度。
五、真正重要的是“边界”，不是名字
很多后端项目失败，不是选错架构名词，
而是边界失控。
一个健康的后端系统，至少要守住这些边界：
Interface 层
- 只做协议适配
- 不写业务、不写 SQL
Application 层
- 负责流程与事务
- 不承载核心业务模型
Domain 层
- 承载业务规则
- 不依赖技术实现
Infrastructure 层
- 只做实现
- 不控制业务
👉 架构是否成立，取决于边界是否干净。
六、MVC 在后端的真实形态
在后端：
- C = Controller（接口层）
- M = Domain + Repository
- V = JSON / VO / Response
也就是说：
👉 后端的 View，已经退化成“数据结构”。
所以行业里仍说 MVC，
但工程上，真正使用的是分层 + 领域模型。
七、一个可直接落地的工程结构模板
interfaces/ http/controller http/dto http/vo http/assembler application/ service command query domain/ model service repository (接口) infrastructure/ persistence client config依赖方向：
interfaces → application → domain infrastructure → domain👉 Domain 不依赖任何外层。
八、总结一句话
👉 后端不是 UI 架构问题，而是业务复杂度与系统演进问题。
👉 后端架构的核心，不是 MVC 这个名字，而是：
- 清晰分层
- 明确边界
- 正确依赖方向
- 稳定业务内核
不管你叫它三层、DDD、洋葱还是六边形，
最终都要回到这四层结构。
九、阶段性结论
后端不用 MVVM / MVP
后端主流是分层 + 领域模型
架构优劣取决于边界，不取决于名字
Domain 层决定系统上限
