Melhor estrutura de projeto Nestj + SOLID

Estrutura nestjs + SOLID

Eu estou estudando NestJS para demandas do trabalho e o sistema que criaremos com essa tecnologia precisa ser extremamente flexível para possibilitar mudanças de algumas fornecedoras de API, futuramente. E você não leu errado, S.O.L.I.D!!!

Eu manjo? Não. Estou aprendendo haha. Então tive duas brilhantes ideias.

1º Mesclar vários códigos que achei na internet utilizando conceitos do SOLID (5 exemplos distintos) e criar um "template" satisfatório nestjs com solid. Para o estudo, eu estou refatorando um CRUD que acabei de finalizar num curso introdutório.

2º Compartilhar com a rede pra polir junto comigo essa refatoração e chegar num modelo massa. E aí, o que que vocês acham? Logo mais compartilho o repositório para a gente trocar uma ideia sobre.

Tecnologias

  • NestJS
  • Typescript
  • TypeORM
  • Envio de email com "@nestjs-modules/mailer"
  • Prisma (pretendo colocar no código também para ver o nível de adaptabilidade do código se precisássemos mudar de orm

Estrutura atual do projeto

├── app
│   ├── app.controller.spec.ts
│   ├── app.controller.ts
│   ├── app.module.ts
│   ├── app.service.ts
│   └── modules
│       └── user
│           ├── dtos
│           │   ├── create-user-dto.ts
│           │   ├── update-patch-user-dto.ts
│           │   └── update-user-dto.ts
│           ├── infra
│           │   └── typeorm
│           │       ├── entities
│           │       │   └── user.entity.ts
│           │       └── repositories
│           │           └── user.repository.ts
│           ├── interfaces
│           │   └── user.interface.ts
│           ├── user.controller.ts
│           ├── user.module.ts
│           └── user.service.ts
├── config
├── core
│   ├── core.module.ts
│   ├── decorators
│   │   ├── param-id.decorator.ts
│   │   ├── roles.decorator.ts
│   │   └── user.decorator.ts
│   ├── enum
│   │   └── role.enum.ts
│   ├── guards
│   │   ├── auth.guard.ts
│   │   └── role.guard.ts
│   ├── interceptors
│   │   └── log.interceptor.ts
│   └── middlewares
│       └── user-id-check.middleware.ts
├── database
├── main.ts
└── shared
    └── auth
        ├── auth.controller.ts
        ├── auth.interfaces.ts
        ├── auth.module.ts
        ├── auth.service.ts
        ├── dtos
        │   ├── auth-forget.dto.ts
        │   ├── auth-login.dto.ts
        │   ├── auth-me.dto.ts
        │   ├── auth-register.dto.ts
        │   └── auth-reset.dto.ts
        ├── infra
        └── service

ps: Como vocês preferem conversar sobre o código? Por aqui mesmo? Discord? issues do github? me dêem ideias 😅

Inversão de dependência no Nest nao funciona tão bem como no ASP.NET, pra conseguir fazer o (DIP) de uma interface vai precisar utilizar um decorator @Inject pra isso. Criar instancias de forma manual acaba sendo muito complexo de gerenciar, porque vc comeca a ter problemas para gerenciamento de variáveis de ambiente em tempo de execução caso queira fazer testes.

Sobre a estrutura de pastas, achei ok, porém nao gosto de comecar uma aplicação dividindo em módulos. Prefiro começar com a estrutura de infra/serviços/domínio e depois dividir em módulos.

├── app
│   ├── domain
│   ├── services
│   ├── infra
│   ├── shared

Porém aí já e gosto pessoal meu kkkkk.

Verdade mano 🤔. Vou apanhar pra fazer os testes rodarem. É bem chato mesmo pra fazer a configuração. Sobre a estrutura de pastas, acho faz sentido principalmente quando não conhecemos todas as entidades da aplicação. Ai começa com uma estrutura mais "genérica" e vai segmentando a medida que a aplicação cresce e os dados se tornam mais claro. É isso?
Tenho esse repo de uma API simples, dps da uma olhada, pode ajudar: https://github.com/daviArttur/bossabox_api. Isso mesmo
Show. Valeu pela referência. Vou dar uma olhada!

Tenho usado um modelo mais simples de código por que também estou começando. Dentro da pasta src eu crio uma pasta para cada contexto do codigo. Exemplo tenho uma pasta User e dentro dela tenho seu module, controller e service. O module app.module recebe o module de cada contexto fazendo a API rodar. Acha que esse método de programar com Nest está incorreto ?

P.S: Já estou usando o prisma como banco de dados.

Não tá incorreto. Tanto que é a forma que a documentação do Nestjs utiliza para repassar o conteúdo. Mas quando seu código for escalar, é interessante segmentar mais essa estrutura utilizando princípios do solid, por exemplo.

Devo ser muito velho viu. Não consigo ver motivo para javascript cuidar de banco de dados, auth, services, etc

Não gosta de javacript para back-end? Poderia compartilhar o seu ponto de vista?
Tem muitas empresas gigantes usando JS ~~TS~~ no backend, principalmente pela maior facilidade de encontrar profissionais, tem muitos programadores que conhecem de JS para o frontend e a barreira para o backend acaba sendo mais os conceitos por trás, afinal a linguagem está no contidiano, mas é bem mais comum JS no backend
Concordo. Fiquei intrigado com o comentário do amigo acima, pois o javascript é uma linguagem que possui algumas inconsistências, imagino que seja pela tipagem fraca. Acredito que a linha de raciocínio dele segue esse caminho.
Olá! Também fiquei curioso em saber o por que não usar o JS no backend. Poderia destrinchar mais o seu ponto de vista?