ddd架构模块结构

架构

领域驱动设计（DDD）的分层架构中，各模块的职责通常如下划分：

api 模块（用户接口层）

• 作用：处理外部请求和响应，定义对外暴露的接口。
• 核心职责：
  • 接收HTTP请求（如RESTful API、GraphQL），进行参数校验和权限认证。
  • 将外部请求的DTO（如请求参数）转换为应用层的输入模型。
  • 将应用层的输出结果转换为对外的响应DTO。
• 典型内容：Controller、DTO、参数校验逻辑、Swagger文档等。

infra 模块（基础设施层）

• 作用：实现技术细节，为其他层提供技术支持。
• 核心职责：
  • 实现领域层定义的仓储接口（如MySQL、MongoDB操作）。
  • 集成第三方服务（如短信、支付、OSS存储）。
  • 消息队列（如Kafka、RabbitMQ）、缓存（Redis）、分布式锁等基础设施的实现。
• 依赖关系：依赖领域层（实现其接口），但领域层不依赖它（依赖倒置原则）。

domain 模块（领域层）

• 作用：系统的核心，封装业务逻辑和领域知识。
• 核心职责：
  • 定义实体（Entity）、值对象（Value Object）、聚合根（Aggregate Root）。
  • 实现领域服务（Domain Service）、领域事件（Domain Event）。
  • 定义仓储接口（Repository Interface，由infra实现）。
• 原则：保持高度内聚，无外部技术依赖（如数据库、框架）。

starter 模块（启动/配置层）

• 作用：封装项目启动和公共配置，提供“开箱即用”的能力。
• 核心职责：
  • 定义Spring Boot自动配置类（如数据库连接池、MyBatis、Redis配置）。
  • 封装通用组件的Starter（如自定义Starter供其他服务复用）。
• 典型内容：@Configuration类、spring.factories配置。

common 模块（通用工具层）

• 作用：提供跨模块的通用工具和基础组件。
• 核心职责：
  • 工具类（日期处理、加密解密、JSON序列化）。
  • 通用常量、枚举、异常类、基础DTO。
  • 全局异常处理、日志切面、公共过滤器。
• 原则：避免包含业务逻辑，保持高度可复用性。

application 模块（应用层）

• 作用：编排领域层逻辑，实现具体的业务用例。
• 核心职责：
  • 定义应用服务（Application Service），协调领域对象完成用例。
  • 处理事务、权限校验、日志记录等横切关注点。
  • 调用领域层的领域服务和仓储接口。
• 子模块划分：
  • job：定时任务逻辑（如使用Quartz或Spring Scheduler）。
  • mq：消息队列的消费者和生产者（如处理订单超时事件）。
  • controller：HTTP请求的入口（部分项目会将Controller放在api模块）。

1. 上层依赖下层：api → application → domain ← infra
2. common和starter：被所有模块依赖（提供通用能力）。
3. domain保持独立：不依赖任何其他模块（仅定义抽象接口）。

---

代码结构

src/
├── api/               # 用户接口层
│   ├── controller/
│   └── dto/
├── infra/             # 基础设施层
│   ├── repository/    # 实现领域层仓储接口
│   └── mq/
├── domain/            # 领域层
│   ├── model/         # 实体、值对象
│   ├── service/       # 领域服务
│   └── repository/    # 仓储接口
├── starter/           # 自动配置
├── common/            # 通用工具
└── application/       # 应用层
    ├── job/           # 定时任务
    ├── mq/            # 消息处理
    └── controller/    # 请求入口（可选）

通过这种分层，系统可以保持高内聚、低耦合，同时明确各模块职责，便于维护和扩展。