DDD架构典型项目结构

以下是一个典型的DDD分层项目结构实例(Java项目)：

src/main/java

├── com.example                  // 项目根包

│   ├── application              // 应用层

│   │   ├── services             // 应用服务（协调领域逻辑）

│   │   ├── dtos                 // 数据传输对象（DTO）

│   │   └── events              // 应用层事件（跨聚合通信）

│   │

│   ├── domain                   // 领域层（核心）

│   │   ├── model                // 领域模型

│   │   │   ├── aggregates       // 聚合根（如OrderAggregate）

│   │   │   ├── entities         // 实体（如OrderItem）

│   │   │   ├── valueobjects     // 值对象（如Money）

│   │   │   └── enums           // 领域枚举（如OrderStatus）

│   │   │

│   │   ├── services            // 领域服务（跨聚合的逻辑）

│   │   ├── repositories        // 仓储接口（定义持久化契约）

│   │   └── events              // 领域事件（如OrderCreatedEvent）

│   │

│   ├── infrastructure           // 基础设施层

│   │   ├── repositories        // 仓储实现（如JPA/Hibernate）

│   │   ├── external            // 外部服务适配器（如支付API）

│   │   ├── config               // 配置类（Spring配置等）

│   │   └── persistence         // 数据库实体（与领域模型分离）

│   │

│   └── interfaces              // 用户界面层（或adapter层）

│       ├── rest                // REST API（Controller）

│       ├── mq                 // 消息队列消费者

│       └── web                // Web页面（如Thymeleaf模板）

│

└── resources

    ├── application.properties  // 配置文件

    └── db/migration           // 数据库迁移脚本（如Flyway）

关键目录说明

1. 应用层(application)

• services：应用服务，负责用例流程协调（无业务逻辑） 
• dtos：数据传输对象，用于接口层与外部系统的数据交换
• events：应用层事件（如触发邮件通知）

2. 领域层

• aggregates: 聚合根（业务一致性边界，如`OrderAggregate`）  
• entities/values: 实体（唯一标识）和值对象（不可变属性）  
• services: 领域服务（处理跨聚合的业务逻辑）  
• repositories: 仓储接口（定义持久化契约，实现由基础设施层提供）

3. 基础设施层

• repositories: 仓储实现（如JPA/Hibernate、MyBatis）  
• external: 外部服务适配器（如调用第三方支付API的Client）  
• persistence: 数据库实体（与领域模型分离，避免污染领域层）

4. 用户界面层

• rest: REST API的Controller（接收HTTP请求，调用应用服务）  
• mq: 消息队列消费者（如处理RabbitMQ/Kafka消息）

模块化变体

对于大型项目，可按照业务模块划分包结构（如订单、支付、库存模块）

├── com.example

│   ├── order                   // 订单模块

│   │   ├── application         // 应用层（订单相关）

│   │   ├── domain              // 领域层（订单模型）

│   │   └── interfaces          // 接口层（订单API）

│   │

│   ├── payment                 // 支付模块

│   │   ├── application         // 应用层（支付相关）

│   │   ├── domain              // 领域层（支付模型）

│   │   └── interfaces          // 接口层（支付API）

│

└── ...

特点总结

• 领域与技术解耦：领域层不依赖具体技术实现（如数据库、框架） 
• 高内聚低耦合：按聚合划分业务边界，避免代码臃肿
• 明确分层职责
  • 接口层：处理输入输出（HTTP/MQ等）
  • 应用层：编排领域对象
  • 领域层：实现核心业务规则  
  • 基础设施层：提供技术实现（数据库、外部服务）

　根据项目规模，可灵活调整结构（例如小项目可合并application层和interfaces层）。