Como estruturar uma aplicação NestJS para crescer

Conteúdo de demonstração. Este artigo foi escrito para validar o layout de artigos do Devnático (sumário, blocos de código, caixas de destaque e tabelas) e será substituído por conteúdo definitivo.

Projetos NestJS costumam nascer organizados e, alguns meses depois, virar uma pasta src com quarenta arquivos sem hierarquia clara. Este guia resume os limites que ajudam a manter a base de código saudável conforme ela cresce.

Comece pelos módulos de domínio

Em vez de organizar pastas por tipo técnico (controllers, services, dtos), agrupe por domínio de negócio. Cada módulo deve representar um conceito real do produto — pedidos, pagamentos, usuarios — e conter tudo o que precisa para funcionar.

@Module({
  imports: [TypeOrmModule.forFeature([Order])],
  controllers: [OrdersController],
  providers: [OrdersService],
  exports: [OrdersService],
})
export class OrdersModule {}

Camadas e limites de responsabilidade

Uma divisão que funciona bem na prática:

Camada	Responsabilidade	Depende de
Controller	Validar entrada, chamar o caso de uso	Service
Service	Regra de negócio	Repository / outros services
Repository	Acesso a dados	ORM / driver do banco

Evite o Service “faz-tudo”

Quando um Service começa a ultrapassar algumas centenas de linhas e a acumular métodos sem relação direta, é sinal de que ele está assumindo mais de uma responsabilidade. Extrair casos de uso específicos (ex: CreateOrderUseCase) ajuda a manter cada peça testável isoladamente.

Testes por camada

• Unitários: cobrem Service e casos de uso, sem banco de dados real.
• Integração: cobrem Repository contra um banco de teste.
• E2E: cobrem o fluxo HTTP completo dos endpoints críticos.

Continue por aqui

Esse é só o ponto de partida. Conforme a aplicação cresce, vale revisitar limites de módulo, extrair bounded contexts e considerar comunicação assíncrona entre domínios.