后端常见分层模型

文章目录一、最经典标准分层从上到下1. 表示层 / 接入层Controller / API2. 应用层 / 服务层Service3. 领域层Domain / Model4. 基础设施层Infrastructure二、最常见简化版企业真实开发 90% 都长这样三、DDD 风格分层复杂业务四、三层架构老经典五、一张表秒懂所有分层六、终极一句话总结一、最经典标准分层从上到下表示层 / 接入层 ↓ 应用层服务层 ↓ 领域层业务核心 ↓ 基础设施层数据、存储、第三方也常被简化成大家最熟的Controller → Service → Dao/Mapper → DB我一层一层讲人话。1. 表示层 / 接入层Controller / API只管“进来的请求”和“返回的结果”。职责接收 HTTP/gRPC 请求参数校验权限、限流、日志调用 Service把结果返回绝不写业务逻辑例子RestControllerRequestMapping(/user)publicclassUserController{GetMapping(/{id})publicResultUserVOgetUser(PathVariableLongid){returnResult.success(userService.getById(id));}}2. 应用层 / 服务层Service业务流程的总指挥。职责编排业务步骤下单→扣库存→付款→通知事务控制调用领域对象/表模块对外提供统一接口它不实现细粒度业务只调度。对应你刚才看的书里服务层 系统的 API界面只跟它交互3. 领域层Domain / Model真正的业务逻辑所在地。三种风格你已经学完了事务脚本一段过程式代码搞定业务表模块一个类管一张表操作记录集领域模型对象自带行为充血模型这一层是系统的“大脑”。4. 基础设施层Infrastructure只管技术不管业务。包括DAO / Mapper / Repository数据库访问缓存、消息队列HTTP客户端、第三方SDK日志、工具类它为上层提供技术能力。二、最常见简化版企业真实开发 90% 都长这样Controller ↓ Service ↓ Model/Entity Dao/Mapper ↓ DBController收请求、返回Service写业务流程、事务Entity纯数据Dao/Mapper查数据库这就是事务脚本 Data Mapper的现实版本。三、DDD 风格分层复杂业务接入层 ↓ 应用层Service只编排 ↓ 领域层Domain Service Entity Value Object ↓ 基础设施层Repo、存储、第三方特点业务逻辑尽量下沉到领域对象Service 只做流程调度数据访问藏在 Repository四、三层架构老经典表示层 业务逻辑层BLL 数据访问层DAL就是BLL ≈ Service DomainDAL ≈ Dao/Mapper简单项目依然非常常用。五、一张表秒懂所有分层层职责不做什么Controller接收请求、参数、返回业务、计算、SQLService流程、事务、调度复杂业务规则Domain业务规则、验证、计算存储、HTTPDao/MapperSQL、读写数据库业务逻辑六、终极一句话总结后端分层 请求从上往下流业务在中间数据在最底下。上层只管接入中间层管业务下层管存储