Padrão Use Case

A camada de aplicação concentra a orquestração de negócio em classes @Injectable() em src/app/use-cases/ (~163 arquivos, organizados por pasta de feature).

Estrutura de um use case

Exemplo simples (um gateway)

// src/app/use-cases/attendance-type/list-attendance-type.use-case.ts
@Injectable()
export class ListAttendanceTypeUseCase {
  constructor(
    private attendanceTypeRepository: AttendanceTypeRepositoryGateway,
  ) {}

  async execute(companyId: number) {
    const attendanceTypes =
      await this.attendanceTypeRepository.findAll(companyId);
    return {
      success: true,
      data: attendanceTypes.map((t) => t.getFriendlyObject()),
    };
  }
}

Exemplo complexo (múltiplos gateways + broker)

ListAttendanceUseCase injeta 7 dependências:

• 6 *RepositoryGateway (attendance, customer, product, queues, tasks, interactions)
• 1 BrokerGateway (para enfileirar exportação de relatório)

Quando sendEmail === true, o use case não busca dados — publica mensagem na fila e retorna reportQueued: true. O processamento pesado ocorre no consumer (Assíncrono e workers).

Convenções de retorno

Serialização de resposta

O padrão dominante é chamar entity.getFriendlyObject() nas entities de src/app/entities/. Isso produz objetos planos adequados para JSON.

Mappers em src/domain/mappers/ são raros — usados quando há DTO de response formal separado (ex.: ServiceOrderResponseMapper).

Registro no NestJS

Use cases não têm módulo próprio por feature. São listados no array USECASES de:

• src/infra/http/http.module.ts
• src/infra/http-public/http.module.ts (subset)
• src/infra/http-internal/http.module.ts (subset)

Ao criar um use case, é obrigatório adicioná-lo ao array correspondente — caso contrário o Nest não consegue injetá-lo no controller.

Próximos tópicos

• Padrão Gateway
• Entities, DTOs e Knex rows
• Injeção de dependências