Java REST API三层架构目录规划与工程实践

1. 项目概述

作为一个在Java后端开发领域摸爬滚打多年的老码农，我见过太多因为项目目录结构混乱而导致的维护噩梦。今天我们就来聊聊REST API项目中最经典的三层架构目录规划，这可不是简单的"分几个包"那么简单，而是关乎整个项目生命周期的工程实践。

三层架构（Controller-Service-DAO）看似基础，但90%的团队都没用对。合理的目录结构应该像城市道路规划一样，让不同职能的代码各归其位，同时为未来的扩展预留空间。我参与过十几个从零到百万级用户量的Java项目，发现前期合理的目录规划能为后期节省至少30%的维护成本。

2. 三层架构核心解析

2.1 传统三层架构的现代演进

经典的Controller-Service-DAO三层在微服务时代已经进化出了更多细节：

code复制src/main/java
├── com.example.project
│   ├── application  # 应用层（原Controller）
│   ├── domain       # 领域层（原Service）
│   ├── infrastructure # 基础设施层（原DAO）
│   └── shared       # 共享组件

这种改进版的DDD风格分层更符合现代Java项目的需求。以用户注册为例：

• application层处理HTTP协议转换
• domain层实现业务规则校验
• infrastructure层完成数据库持久化

2.2 各层职责边界定义

重要原则：上层可以调用下层，下层绝对不允许调用上层

1. Application层：

   • 只做参数校验和DTO转换
   • 禁止出现业务逻辑
   • 典型类命名：XxxController、XxxDTO

2. Domain层：

   • 核心业务逻辑所在地
   • 应该保持POJO纯净性
   • 典型类命名：XxxService、XxxEntity

3. Infrastructure层：

   • 数据库访问实现
   • 第三方服务集成
   • 典型类命名：XxxRepository、XxxMapper

3. 实战目录规划

3.1 基础目录结构示例

这是经过多个生产项目验证