在很多 Java 后端项目中常见的项目结构通常是这样controller service mapper entity这种结构在小项目中问题不大但随着系统复杂度上升很容易出现Service 变成巨型类God Service业务逻辑、数据库代码、第三方调用混在一起不同业务之间耦合严重项目越来越难维护因此在中大型项目中通常会采用DDDDomain Driven Design领域驱动设计的结构并且先按业务拆分模块再在每个业务模块内部做 DDD 分层。核心思想先分业务模块 再在模块内部做 DDD 分层一、为什么需要这种结构传统三层结构Controller Service Mapper随着业务增加很容易变成UserService ├─ 调 mapper ├─ 调 redis ├─ 调 mq ├─ 调 api ├─ 写业务规则 ├─ 写流程逻辑最终变成Service 巨型业务类问题包括业务逻辑与技术实现混在一起不同业务之间互相调用修改一个功能可能影响多个模块DDD 的目标就是让业务逻辑独立出来技术实现解耦。二、项目整体结构采用按业务拆分模块的方式project │ ├── modules │ ├── user │ ├── order │ ├── pay │ └── ai │ ├── shared │ ├── resources │ └── ProjectApplication.java其中modules 各业务模块 shared 公共模块三、业务模块内部结构DDD 分层每个业务模块内部再做DDD 分层设计user │ ├── controller ├── application ├── domain ├── infrastructure ├── dto └── assembler完整示例user │ ├── controller │ └── UserController.java │ ├── application │ ├── service │ │ └── UserApplicationService.java │ ├── command │ │ └── CreateUserCommand.java │ └── query │ └── UserQueryService.java │ ├── domain │ ├── model │ │ └── User.java │ ├── repository │ │ └── UserRepository.java │ ├── service │ │ └── UserDomainService.java │ └── event │ └── UserCreatedEvent.java │ ├── infrastructure │ ├── persistence │ │ ├── mapper │ │ │ └── UserMapper.java │ │ ├── dataobject │ │ │ └── UserDO.java │ │ └── repository │ │ └── UserRepositoryImpl.java │ │ │ ├── cache │ │ └── UserCacheRepository.java │ │ │ ├── client │ │ └── SmsClient.java │ │ │ └── mq │ └── UserProducer.java │ ├── dto │ ├── CreateUserRequest.java │ └── UserResponse.java │ └── assembler └── UserAssembler.java四、各层职责1 Controller接口层职责接收 HTTP 请求 参数校验 调用 Application 层 返回结果示例RestController public class UserController { private final UserApplicationService userApplicationService; PostMapping(/users) public UserResponse createUser(RequestBody CreateUserRequest request) { return userApplicationService.createUser(request); } }2 Application应用层职责业务流程编排 事务控制 调用 DomainApplication 层不写业务规则只负责流程。例如创建用户 发送短信 记录日志3 Domain领域层这是DDD 的核心层。职责业务规则 领域模型 领域能力例如用户必须唯一 订单金额必须大于0 库存不足不能下单Domain 常见结构model repository service event其中repository 只定义接口示例public interface UserRepository { User findById(Long id); void save(User user); }4 Infrastructure基础设施层职责实现 Domain 接口 与外部技术资源交互例如数据库 Redis MQ 第三方 API示例Repository public class UserRepositoryImpl implements UserRepository { private final UserMapper userMapper; Override public User findById(Long id) { UserDO userDO userMapper.selectById(id); return convert(userDO); } }五、Shared 公共模块项目中通常会有一个shared 模块shared │ ├── config ├── common ├── exception ├── security ├── util └── enums例如统一返回 Result 全局异常处理 工具类 配置类 安全组件六、DDD 最核心思想DDD 的核心原则是Domain 定义能力Infrastructure 实现能力。例如Domain └── UserRepository接口 Infrastructure └── UserRepositoryImpl实现这样可以实现业务规则 与 技术实现 解耦例如未来MySQL → MongoDB Redis → Memcached Kafka → RocketMQ只需要修改InfrastructureDomain 层无需变化。七、总结DDD 模块化结构可以总结为先按业务拆模块 再在模块内部做 DDD 分层每层职责controller 接口入口 application 业务流程编排 domain 业务规则 infrastructure 技术实现 dto 请求响应对象 assembler 对象转换 shared 公共组件最终实现业务模块清晰 技术实现解耦 系统更易维护和扩展八、一句话理解 DDDDomain 定义能力Infrastructure 实现能力。下一篇再升级一版“大厂级项目结构”增加 facade / executor / event / acl / consumer / converter 等那一版会更接近真正大型互联网项目架构。Java 后端项目结构设计DDD 模块化架构大厂级项目结构