Java框架中的分层架构

分层架构

Entity层（实体层）

作用：定义数据模型，与数据库表结构对应
职责：封装业务对象的属性和基本操作
特点：通常是简单的POJO类，包含属性、getter/setter方法
示例：用户实体类User包含id、name、email等属性

Mapper层（持久层/数据访问层）

作用：负责与数据库交互，执行CRUD操作
职责：提供数据访问接口，实现SQL语句的执行
特点：通常使用MyBatis、JPA等框架实现
功能：将数据库记录映射为实体对象

Service层（业务逻辑层）

作用：处理具体的业务逻辑
职责：实现业务规则和流程控制，协调多个Mapper的操作，处理事务管理
特点：不关心具体的数据存储细节

Controller层（控制器层）

作用：接收HTTP请求并返回响应结果
职责：接收前端参数，调用相应的Service方法，返回视图或JSON数据
特点：关注请求路由、参数校验和响应格式

分层架构限制原则

单一职责原则

每个服务类只负责一个业务领域
避免在一个 Service 中混合多个不相关的业务逻辑
保持代码的可读性和可维护性

开闭原则

对扩展开放，对修改关闭
通过接口和抽象类实现灵活的业务扩展
避免频繁修改现有的稳定代码

接口隔离原则

Service 层提供细粒度的业务接口
避免臃肿的大接口，保持接口的专注性
客户端只依赖需要的接口方法

事务边界控制

事务管理集中在 Service 层
Controller 层不应处理事务逻辑
避免跨层的事务传播问题

异常处理分层

Mapper 层抛出数据访问异常
Service 层捕获并转换为业务异常
Controller 层统一处理异常响应

数据传输对象（DTO）规范

跨层传递使用专门的 DTO 对象
避免直接传递 Entity 对象
控制数据安全和格式标准化

依赖注入约束

严格遵循分层依赖关系
下层组件不能依赖上层组件
通过 @Autowired 或构造器注入实现解耦

跨模块Service调用限制

架构层次规范

Service层 应该作为业务逻辑的协调者
只能依赖同层级的其他 Service 组件
不应直接访问底层的 Mapper 数据访问层

依赖倒置原则

Controller → Service → Service → Mapper
遵循高层模块不依赖低层模块的原则
跨模块调用应该通过业务接口抽象

避免循环依赖

直接调用其他模块 Mapper 容易造成紧耦合
通过 Service 层调用可以解耦模块间的关系
维护清晰的模块边界

事务管理统一

Service 层统一处理事务边界
避免跨模块直接 Mapper 调用导致事务不一致
保证数据一致性

业务逻辑封装

Service 层提供完整的业务能力封装
不应暴露底层数据访问细节
保持业务逻辑的完整性