写后端写了一段时间后，很多人都会产生一个困惑：

👉 到底什么是“后端架构”？
👉 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 层决定系统上限