后端常见分层模型

文章目录

一、最经典标准分层（从上到下）
[1. 表示层 / 接入层（Controller / API）](#1. 表示层 / 接入层（Controller / API）)
[2. 应用层 / 服务层（Service）](#2. 应用层 / 服务层（Service）)
[3. 领域层（Domain / Model）](#3. 领域层（Domain / Model）)
[4. 基础设施层（Infrastructure）](#4. 基础设施层（Infrastructure）)
[二、最常见简化版（企业真实开发 90% 都长这样）](#二、最常见简化版（企业真实开发 90% 都长这样）)
[三、DDD 风格分层（复杂业务）](#三、DDD 风格分层（复杂业务）)
四、三层架构（老经典）
五、一张表秒懂所有分层
六、终极一句话总结

一、最经典标准分层（从上到下）

复制代码

表示层 / 接入层
  ↓
应用层（服务层）
  ↓
领域层（业务核心）
  ↓
基础设施层（数据、存储、第三方）

也常被简化成大家最熟的：

复制代码

Controller → Service → Dao/Mapper → DB

我一层一层讲人话。

1. 表示层 / 接入层（Controller / API）

只管"进来的请求"和"返回的结果"。

职责：

接收 HTTP/gRPC 请求
参数校验
权限、限流、日志
调用 Service，把结果返回

绝不写业务逻辑！

例子：

java 复制代码

@RestController
@RequestMapping("/user")
public class UserController {
    @GetMapping("/{id}")
    public Result<UserVO> getUser(@PathVariable Long id) {
        return Result.success(userService.getById(id));
    }
}

2. 应用层 / 服务层（Service）

业务流程的总指挥。

职责：

编排业务步骤（下单→扣库存→付款→通知）
事务控制
调用领域对象/表模块
对外提供统一接口

它不实现细粒度业务，只调度。

对应你刚才看的书里：

服务层 = 系统的 API，界面只跟它交互

3. 领域层（Domain / Model）

真正的业务逻辑所在地。

三种风格你已经学完了：

事务脚本：一段过程式代码搞定业务
表模块：一个类管一张表，操作记录集
领域模型：对象自带行为（充血模型）

这一层是系统的"大脑"。

4. 基础设施层（Infrastructure）

只管技术，不管业务。

包括：

DAO / Mapper / Repository（数据库访问）
缓存、消息队列
HTTP客户端、第三方SDK
日志、工具类

它为上层提供技术能力。

二、最常见简化版（企业真实开发 90% 都长这样）

复制代码

Controller
   ↓
Service
   ↓
Model/Entity + Dao/Mapper
   ↓
DB

Controller：收请求、返回
Service：写业务流程、事务
Entity：纯数据
Dao/Mapper：查数据库

这就是 事务脚本 + Data Mapper 的现实版本。

三、DDD 风格分层（复杂业务）

复制代码

接入层
  ↓
应用层（Service，只编排）
  ↓
领域层（Domain Service + Entity + Value Object）
  ↓
基础设施层（Repo、存储、第三方）

特点：

业务逻辑尽量下沉到领域对象
Service 只做流程调度
数据访问藏在 Repository

四、三层架构（老经典）

复制代码

表示层
业务逻辑层（BLL）
数据访问层（DAL）

就是：

BLL ≈ Service + Domain
DAL ≈ Dao/Mapper

简单项目依然非常常用。

五、一张表秒懂所有分层

层	职责	不做什么
Controller	接收请求、参数、返回	业务、计算、SQL
Service	流程、事务、调度	复杂业务规则
Domain	业务规则、验证、计算	存储、HTTP
Dao/Mapper	SQL、读写数据库	业务逻辑

六、终极一句话总结

后端分层 = 请求从上往下流，业务在中间，数据在最底下。

上层只管接入
中间层管业务
下层管存储