Java REST API三层架构项目目录规划

Java REST API三层架构项目目录规划

背景与技术栈选择

采用Spring Boot + Mybatis + Maven技术栈的微服务项目，需通过目录结构而非Module实现分层。目录规范是工程化基础，直接影响开发效率、标准化交付及DevOps流程衔接。

核心分层与业务划分

• controller层 按业务功能划分子包（如order、payment），类名以Controller结尾。适配业务多样性，避免按技术维度拆分。
• service层 与controller层保持相同业务划分，接口以Service命名，实现类加Impl后缀（如OrderServiceImpl）。
• dao层 按数据源划分子包（如db.order、db.payment），类名以Mapper结尾。MyBatis的XML文件置于resources/mapper对应子路径。

数据实体管理规范

• 自动生成代码隔离 自动生成的PO类存放于po.db.{dbname}.generator，手动扩展类置于po.db.{dbname}.custom。Mapper接口与XML文件同理隔离。
• DTO/VO独立分层 传输对象按用途分层：dto.request（入参）、dto.response（出参）、vo（视图对象）。避免与PO混用。

配置与工具类管理

• 配置集中化 config包下按类型细分：enums（枚举）、properties（配置项）、kafka（消息队列配置）。常量类Constants归入此包。
• 工具类统一存放 util包收纳所有工具类，命名以Util结尾（如DateUtil）。避免分散到业务包中。

示例目录结构

src/main/java
└── com.example
    ├── config
    │   ├── enums
    │   ├── kafka
    │   └── RedisConfig.java
    ├── controller
    │   ├── order
    │   │   └── OrderController.java
    │   └── payment
    ├── service
    │   ├── impl
    │   └── OrderService.java
    ├── dao
    │   ├── db
    │   │   ├── order
    │   │   └── payment
    ├── po
    │   ├── db
    │   │   ├── order
    │   │   │   ├── custom
    │   │   │   └── generator
    ├── dto
    │   ├── request
    │   └── response
    └── util
        └── JsonUtil.java
resources
└── mapper
    ├── order
    └── payment

关键设计原则

1. 隔离自动生成代码：防止后续生成覆盖人工修改，通过物理目录隔离（generator/custom）。
2. 业务导向分包：controller/service按业务划分，dao按数据源划分，平衡灵活性与一致性。
3. 明确传输对象分层：严格区分PO（持久化对象）、DTO（传输对象）、VO（展示对象）。

此结构支持快速定位代码，适应业务扩展，同时满足微服务“小而自治”的要求。实际应用中可根据团队习惯调整子包深度，但需保持核心分层逻辑一致。