src
├── user
│   ├── application        # 应用层（服务）
│   ├── domain             # 领域层（实体、值对象、聚合、领域服务）
│   ├── infrastructure     # 基础设施（repository 实现、数据库适配）
│   └── interface          # 接口层（controller、DTO）
│
├── order
│   ├── application
│   ├── domain
│   ├── infrastructure
│   └── interface
│
└── shared                 # 公共模块（异常、日志、事件总线等）

特点：

业务逻辑主要在 domain 层
controller 不写业务逻辑，只调用 application service
数据库逻辑封装在 repository，对 domain 透明

举个例子（订单下单流程）

Controller (Interface 层)

@Post('create')
async create(@Body() dto: CreateOrderDto) {
  return this.orderAppService.createOrder(dto);
}

Application Service (应用层)

@Injectable()
export class OrderAppService {
  constructor(private readonly orderDomainService: OrderDomainService) {}

  async createOrder(dto: CreateOrderDto) {
    // 业务编排
    return this.orderDomainService.create(dto.userId, dto.productId, dto.amount);
  }
}

Domain Service (领域层)

@Injectable()
export class OrderDomainService {
  constructor(private readonly orderRepo: OrderRepository) {}

  create(userId: string, productId: string, amount: number) {
    const order = Order.create(userId, productId, amount);
    order.validate(); // 业务规则校验
    return this.orderRepo.save(order);
  }
}

Infrastructure（基础设施层）

export class Order {
  constructor(
    private readonly id: string,
    private readonly userId: string,
    private readonly productId: string,
    private amount: number,
  ) {}

  static create(userId: string, productId: string, amount: number) {
    return new Order(uuid(), userId, productId, amount);
  }

  validate() {
    if (this.amount <= 0) throw new Error('订单金额必须大于 0');
  }
}

DDD 架构的特点是 业务逻辑内聚在领域层，上层（Controller、Service）只做编排和协调。 NestJS 本身的模块化和依赖注入机制，和 DDD 思路非常契合。

重要

误区：Service 就是写业务逻辑的地方（比如 CRUD 全写在一个 Service 里）。

进阶理解：Service 并不是 实现业务逻辑的唯一地方，而是一个 业务组织者。

DDD 的典型分层

Interface（用户接口层 / 控制器层）
- 就是你写的 NestJS Controller、GraphQL Resolver、gRPC Handler 之类。
- 负责接收请求（HTTP、WebSocket…），调用应用层，不写业务。
- 只负责入站适配。
Application（应用层）
- 定义系统对外提供的用例（Use Case）。
- 这里不会写具体业务逻辑，而是编排领域服务，把多个业务过程串起来。
- 举例：订单支付 → 校验库存 (InventoryService) → 扣减库存 → 扣钱 → 创建订单 → 发送通知。
- 主要职责：
  - 协调领域层
  - 事务控制
  - 权限校验、日志记录等
Domain（领域层）
- 核心业务逻辑所在。
- 包含 实体 (Entity)、值对象 (Value Object)、领域服务 (Domain Service)。
- 这里不关心数据库、不关心 HTTP，只关注业务规则本身。
- 举例：
  - 订单实体（有状态：已支付/未支付）
  - 支付服务（校验支付金额，检查订单状态）
  - 值对象（金额 Money，不能为负数）
Infrastructure（基础设施层）
- 技术细节的实现：数据库、消息队列、缓存、第三方 API 调用等。
- 通常提供 Repository 实现，把数据存取和业务解耦。
- 在 NestJS 里一般是 PrismaService、TypeORM Repository、RedisService、KafkaAdapter 等。
- 在 Domain 里只定义接口，在 Infrastructure 里写实现。

                         ┌───────────────────┐
                         │   Interface 层    │  ← 控制器/入站适配
                         │ (Controller/API)  │
                         └─────────┬─────────┘
                                   │ 调用
                                   ▼
                         ┌───────────────────┐
                         │  Application 层   │  ← 应用服务 (Use Case)
                         │ (App Service)     │
                         │ - 业务编排        │
                         │ - 事务控制        │
                         └─────────┬─────────┘
                                   │ 调用
                                   ▼
                         ┌───────────────────┐
                         │    Domain 层      │  ← 业务核心
                         │ (Entity, VO,      │
                         │  Domain Service)  │
                         │ - 规则 if/else    │
                         │ - 聚合/状态管理    │
                         └─────────┬─────────┘
                                   │ 调用接口
                                   ▼
                         ┌───────────────────┐
                         │ Infrastructure 层 │  ← 技术细节
                         │ (DB, MQ, Cache,   │
                         │  3rd API, Repo)   │
                         └───────────────────┘

Interface，Types/DTO的位置

抽象接口

一般是 “领域接口”（例如 Repository、Domain Service 需要依赖的外部服务接口）。

放在领域层 (Domain)
- 因为接口描述的是领域的需求，而不是某个具体技术。
- 比如领域层需要一个「用户仓储」，它不关心用的是 MySQL、Mongo 还是 Redis。
- 这个接口属于领域的“所有权”，实现交给 Infrastructure。

例子：

// src/domain/user/user.repository.ts
export interface UserRepository {
  findById(id: string): Promise<User>;
  save(user: User): Promise<void>;
}

然后在基础设施层实现：

// src/infrastructure/repositories/user.repository.mysql.ts
@Injectable()
export class MysqlUserRepository implements UserRepository {
  async findById(id: string): Promise<User> { ... }
  async save(user: User): Promise<void> { ... }
}

原则：接口属于领域，实现在 Infrastructure。这样领域层只依赖抽象，不依赖技术细节。

DTO / 输入输出类型

DTO 是应用层（Application）的东西，通常不放在领域层，因为它是为了 接口通信/数据传输 服务的。

DTO 属于应用层或接口层，而不是领域层。
领域层只关心领域模型（Entity、ValueObject），而不是网络请求/响应格式。

例子：

// src/application/user/dto/create-user.dto.ts
export class CreateUserDto {
  username: string;
  password: string;
}

控制器用它来接收输入：

@Post()
create(@Body() dto: CreateUserDto) {
  return this.userAppService.create(dto);
}

通用类型（Shared Types）

一些纯工具类的类型（例如 Result<T>、Paginated<T>），可以单独放在 shared/ 或 common/ 文件夹里。

这类跟领域无关，也不是 DTO，而是“跨层共用”的通用结构。

例子：

// src/shared/result.ts
export type Result<T> = {
  success: boolean;
  data?: T;
  error?: string;
};

总结

接口 (Repository, Service Contracts) → 放在领域层 （因为它描述的是领域需求，保持“高内聚，低耦合”）

DTO、入参出参 → 放在应用层/接口层 （因为它是通信协议的一部分，不属于领域）

通用工具类型 → 放在 shared/common 层 （避免污染领域和应用）

一个典型 Nest + DDD 项目目录

src/
  domain/
    user/
      user.entity.ts
      user.repository.ts   <-- 接口
      user.service.ts
  application/
    user/
      user.service.ts
      dto/
        create-user.dto.ts
        update-user.dto.ts
  infrastructure/
    repositories/
      user.repository.mysql.ts   <-- 实现
  interface/
    user.controller.ts
  shared/
    result.ts
    pagination.ts