Pular para conteúdo

Estrutura de diretórios

Padronizar a estrutura de projetos é essencial para o trabalho em equipe, independentemente da linguagem utilizada. A padronização traz os seguintes benefícios:

  • Facilita a colaboração: Uma estrutura padronizada permite que a equipe encontre e organize os arquivos relevantes com facilidade, o que agiliza e torna mais eficiente a colaboração entre os membros do time.
  • Promove a consistência: Manter uma estrutura uniforme garante a organização coerente dos arquivos em todos os projetos da equipe, facilitando a criação e manutenção de uma base de códigos e documentação consistentes em toda a empresa.
  • Facilita a manutenção: Com uma estrutura padronizada, a manutenção e atualização do código tornam-se mais fáceis, uma vez que a função de cada arquivo é facilmente compreendida pelos membros da equipe. Isso economiza tempo e reduz a possibilidade de erros.
  • Reduz o tempo de treinamento: Uma estrutura padronizada permite que novos membros da equipe se adaptem rapidamente e se tornem produtivos mais cedo, já que não precisam gastar tempo procurando arquivos ou entendendo a estrutura do projeto.
  • Promove a reutilização de código: Com uma estrutura padronizada, os membros da equipe podem encontrar e reutilizar facilmente o código em diferentes partes do projeto, economizando tempo e contribuindo para a manutenção de uma base de código uniforme em toda a empresa.

Com o objetivo de garantir a padronização nos projetos mantidos e gerenciados pela empresa, estabeleceu-se uma estrutura de diretórios e arquivos para cada projeto de acordo com a linguagem/framework usado na construção, conforme demonstrado abaixo:

.
├── manifests # (1)!
   ├── k8s # (2)!
       ├── deploy.template.yaml # (3)!
├── perf # (4)!
├── src # (5)!
   ├── main # (6)!
       ├── java # (7)!
           ├── <domain>.<project name>.client # (8)!
           ├── <domain>.<project name>.configuration # (9)!
           ├── <domain>.<project name>.constant # (10)!
           ├── <domain>.<project name>.controller # (11)!
           ├── <domain>.<project name>.domain # (12)!
           ├── <domain>.<project name>.domain.converter # (13)!
           ├── <domain>.<project name>.domain.document # (14)!
           ├── <domain>.<project name>.domain.dto # (15)!
           ├── <domain>.<project name>.domain.dto.nested # (16)!
           ├── <domain>.<project name>.domain.entity # (17)!
           ├── <domain>.<project name>.domain.enumeration # (18)!
           ├── <domain>.<project name>.domain.mapper # (19)!
           ├── <domain>.<project name>.domain.vo # (20)!
           ├── <domain>.<project name>.domain.vo.nested # (21)!
           ├── <domain>.<project name>.exception # (22)!
           ├── <domain>.<project name>.repository # (23)!
           ├── <domain>.<project name>.repository.elastic # (24)!
           ├── <domain>.<project name>.repository.jpa # (25)!
           ├── <domain>.<project name>.repository.jpa.specification # (26)!
           ├── <domain>.<project name>.repository.mongo # (27)!
           ├── <domain>.<project name>.scheduler # (28)!
           ├── <domain>.<project name>.service # (29)!
           ├── <domain>.<project name>.service.impl # (30)!
           ├── <domain>.<project name>.util # (31)!
           ├── <domain>.<project name>.validator # (32)!
       ├── resources # (33)!
           ├── templates # (34)!
               ├── emails # (35)!
               ├── reports # (36)!
           ├── application.properties # (37)!
           ├── messages_pt_BR.properties # (38)!
   ├── test # (39)!
       ├── java # (40)!
       ├── resources # (41)!
           ├── fixtures # (42)!
           ├── scenarios # (43)!
           ├── tools # (44)!
           ├── application-test.properties # (45)!
           ├── logback-test.xml # (46)!
├── target # (47)!
   ├── classes # (48)!
   ├── failsafe-reports # (49)!
   ├── site # (50)!
       ├── jacoco # (51)!
       ├── jacoco-it # (52)!
       ├── jacoco-ut # (53)!
   ├── surefire-reports # (54)!
├── tools # (55)!
   ├── postman # (56)!
├── .settings # (57)!
├── Dockerfile # (58)!
├── docker-compose.yml # (59)!
├── lombok.config # (60)!
├── Makefile # (61)!
├── pom.xml # (62)!
├── README.md # (63)!
├── .gitignore # (64)!
└── .gitlab-ci.yml # (65)!
  1. Diretório contendo os arquivos de configuração aplicados nos ambientes (Infrastructure as Code ⧉) durante a implantação da aplicação.
  2. Este diretório contém os arquivos .yaml que são aplicados no cluster Kubernetes ⧉, seja ele provisionado em provedores de nuvem ou em datacenters on-premise.
  3. Esse arquivo .yaml é utilizado para implantar a aplicação no cluster Kubernetes ⧉, definindo a imagem Docker ⧉, as variáveis de ambiente, o número de réplicas e o mecanismo de redimensionamento com base na demanda. Essa configuração é realizada por meio dos recursos Deployment ⧉, Service ⧉ e HorizontalPodAutoscaler ⧉ disponibilizados pela API do Kubernetes.
  4. Contém o código-fonte para executar o teste de desempenho da aplicação.
  5. Diretório com o código-fonte do projeto.
  6. Contém o código-fonte e recursos que se tornam parte do artefato publicado .jar.
  7. Código-fonte Java ⧉ para o artefato.
  8. Este pacote contém as classes responsáveis pela comunicação com APIs externas ao projeto.
  9. Este pacote contém as classes responsáveis por configurar o funcionamento da aplicação implementada com o framework Spring Boot ⧉.
  10. Este pacote contém classes de constantes que possuem atributos estáticos utilizados em diferentes partes da aplicação.
  11. Este pacote contém as classes que lidam com as requisições HTTP recebidas pela aplicação e as convertem em chamadas aos serviços apropriados. É recomendável ler sobre o pattern Front Controller ⧉.
  12. Este pacote armazena as classes que representam os objetos de domínio da aplicação, ou seja, as classes que modelam as entidades e regras de negócio do sistema.
  13. Este pacote contém as classes responsáveis por realizar a conversão dos valores fornecidos pelo usuário para os atributos de um objeto. Por exemplo, pode conter as classes usadas pelas anotações do JPA ⧉.
  14. Este pacote contém as classes que representam os objetos de negócio da aplicação e que serão armazenados em um banco de dados não relacional (NoSQL ⧉). Por exemplo, pode conter as classes usadas para mapear as coleções do MongoDB ⧉, índices do Elasticsearch ⧉, hashes do Redis ⧉, entre outros.
  15. Este pacote contém as classes utilizadas para transferir dados da camada de serviço <domain>.<project name>.service para a camada de controle <domain>.<project name>.controller. É recomendável ler sobre o pattern Data Transfer Object ⧉.
  16. Este pacote contém as classes que são usadas exclusivamente para tipificar os atributos que são mapeados nos objetos definidos dentro do pacote <domain>.<project name>.domain.dto.
  17. Este pacote contém as classes que representam as entidades de negócio da aplicação e que serão armazenadas em um banco de dados relacional, ou seja, equivalem as tabelas do banco de dados.
  18. Este pacote contém definições de enumerações que são amplamente utilizadas em toda a aplicação. As enumerações são tipos de dados que consistem em um conjunto fixo de valores possíveis, também conhecidos como "elementos" ou "constantes". Elas são úteis para representar categorias, tipos ou estados relevantes para a lógica do negócio em questão.
  19. Este pacote contém classes que realizam a conversão entre diferentes tipos de objetos, tais como VOs, DTOs, entidades e documentos. Para facilitar esse processo, há excelentes bibliotecas, como o MapStruct ⧉.
  20. Este pacote contém as classes utilizadas para transferir dados da camada de controle <domain>.<project name>.controller para a camada de serviço <domain>.<project name>.service. É recomendável ler sobre o pattern Value Object ⧉.
  21. Este pacote contém as classes usadas apenas para tipificar os atributos mapeados nos objetos definidos diretamente no pacote <domain>.<project name>.domain.vo.
  22. Este pacote contém as classes personalizadas de exceção para lidar com erros específicos que podem surgir durante a execução da aplicação. Essas classes oferecem informações detalhadas sobre o tipo de erro, tornando sua identificação e correção mais fácil. É altamente recomendado utilizar essas classes em vez das exceções padrão do Java, pois tornam as exceções lançadas pela aplicação mais descritivas e úteis tanto para os usuários quanto para os desenvolvedores.
  23. Este pacote contém as classes que implementam o padrão Repository ⧉, amplamente utilizado no desenvolvimento de software. O padrão Repository separa a lógica de negócios da camada de persistência de dados, abstraindo o acesso aos dados. Isso simplifica o código da aplicação e torna a manutenção e os testes mais fáceis.
  24. Este pacote contém as classes que implementam a interface de repositório para o banco de dados Elasticsearch ⧉, fornecendo métodos para criar, recuperar, atualizar e excluir documentos dos índices.
  25. Este pacote contém as classes que implementam a interface de repositório para um banco de dados relacional usando a especificação JPA, fornecendo métodos para criar, recuperar, atualizar e excluir registros das tabelas.
  26. Este pacote contém as classes que implementam o pattern Specification ⧉, o qual é amplamente utilizado no desenvolvimento de software para combinar regras de negócio usando lógica booleana. Essas classes são usadas para definir os critérios dos filtros aplicados nas queries executadas na base de dados.
  27. Este pacote contém as classes que implementam a interface de repositório para o banco de dados MongoDB ⧉, fornecendo métodos para criar, recuperar, atualizar e excluir documentos das coleções.
  28. Este pacote contém as classes que definem o agendamento de tarefas a serem executadas regularmente, como atualizações de dados, envio de e-mails, processamento em lote, entre outras.
  29. Este pacote contém as classes que encapsulam a lógica de negócio da aplicação. Essas classes fornecem uma camada de serviço ⧉ para centralizar a construção da lógica de negócio, evitando a duplicação de código ao lidar com diferentes tipos de interface para os dados da aplicação.
  30. Este pacote contém as classes que implementam as interfaces definidas para operações que tratam as regras de negócio da aplicação.
  31. Este pacote contém classes utilitárias com métodos estáticos que podem ser aplicados em diversas funcionalidades de uma aplicação. Essas classes oferecem recursos comuns, como manipulação de texto, formatação de datas, manipulação de arquivos, algoritmos de ordenação, entre outras, que são amplamente úteis em qualquer projeto Java. Geralmente, as classes incluídas neste pacote são candidatas ideais para serem movidas para uma biblioteca compartilhada entre os projetos da equipe de desenvolvimento.
  32. Este pacote contém as classes que permitem a validação de dados em classes que modelam o domínio da aplicação, seguindo a especificação do Bean Validation ⧉. Essas validações são aplicadas nas classes do pacote <domain>.<project name>.domain por meio de anotações.
  33. Arquivos de configuração e outros, como: i18n, XML, YAML e configuração de ambiente
  34. Diretório usado para armazenar os templates HTML de e-mails e relatórios utilizados pela aplicação.
  35. Armazena os arquivos que definem a estrutura das mensagens de e-mail gerenciada pela aplicação.
  36. Armazena os arquivos usados na geração dos relatórios com formato .pdf a partir dos templates HTML.
  37. Arquivo que permite configurar o comportamento da aplicação Spring Boot ⧉.
  38. Arquivo responsável por armazenar as mensagens usadas como respostas nas requisições atendidas dos usuários.
  39. Contém todo o código de teste e recursos.
  40. Código-fonte Java ⧉ para os testes.
  41. Arquivos de configuração e outros usados nos testes.
  42. Este diretório tem como finalidade armazenar arquivos de dados predefinidos, os quais são utilizados como "massa de teste" durante a execução dos testes automatizados. Esses arquivos podem ser de diferentes formatos, tais como JSON ⧉ para testar APIs RESTful, imagens para testar endpoints que permitem o upload de arquivos, entre outros.
  43. Este diretório contém os arquivos (versões atual e esperada dos dados), utilizados nas assertivas dos cenários de teste executados a partir dos testes implementados no projeto. Esses cenários são baseados nos critérios de aceitação definidos na estória ou caso de uso elaborado pelos analistas de negócios junto ao cliente.
  44. Este diretório contém as ferramentas utilizadas para preparar e configurar os serviços provisionados pela aplicação durante a execução dos testes, incluindo arquivos .sql, .sh e .json. Aqui são armazenadas as DDLs usadas para criar bancos de dados, tabelas, procedures e functions, bem como os dados predefinidos utilizados para popular tabelas, coleções ou índices.
  45. Este arquivo é fundamental para configurar o comportamento da aplicação Spring Boot ⧉ durante a execução dos testes. Ele é comumente utilizado para substituir as configurações presentes no arquivo application.properties ⧉, permitindo assim que sejam usados serviços dedicados para a realização dos testes, como aqueles iniciados localmente por meio de ferramentas como o Docker Compose ⧉ ou Testcontainers ⧉.
  46. Este arquivo é utilizado em uma aplicação Spring Boot ⧉ para configurar o comportamento do registro de logs durante a execução dos testes. Ele permite especificar os níveis de log que serão exibidos, o formato da saída dos logs e o destino da saída, como o console ou um arquivo de log específico para testes.
  47. Diretório criado pelo Maven ⧉. Ele contém todas as classes compiladas, arquivos JAR ⧉, etc.
  48. Contém a classes Java ⧉ compiladas (.class).
  49. Esse diretório contém os relatórios em XML dos testes de integração executados pelo plugin Maven Failsafe Plugin ⧉, mostrando detalhes das falhas, erros e resultados.
  50. Diretório com os relatórios de cobertura dos testes unitários e de integração gerados após a execução dos testes.
  51. Contém os arquivos do relatório de cobertura de todos os testes.
  52. Contém os arquivos do relatório de cobertura dos testes de integração.
  53. Contém os arquivos do relatório de cobertura dos testes unitários.
  54. Esse diretório contém os relatórios em XML dos testes unitários executados pelo plugin Maven Surefire Plugin ⧉, mostrando detalhes das falhas, erros e resultados.
  55. Diretório com ferramentas (scripts) auxiliares a manutenção do projeto.
  56. Contém o arquivo .json exportado a partir da ferramenta Postman ⧉ com os endpoints do projeto.
  57. Diretório criado ao importar o projeto na IDE. (não é versionado)
  58. Contém todos os comandos necessários para construir a imagem Docker ⧉ que contém a aplicação empacotada no formato .jar.
  59. Arquivo que permite provisionar os serviços usados pelo teste de integração.
  60. Arquivo de configuração que permite excluir da análise do Sonar ⧉ o código gerado pelo Lombok ⧉.
  61. Utilitário Linux ⧉ que facilita a execução de scripts usados na manutenção do projeto, tais como build, lint, test, entre outros.
  62. Define as dependências e os plugins necessários para a construção de um projeto Maven ⧉.
  63. Página de documentação do projeto (escrito com Markdown ⧉).
  64. Permite ignorar arquivos que ainda não são rastreáveis no Git ⧉.
  65. Configuração do pipeline CI/CD ⧉ no Gitlab ⧉.
.
├── build # (1)!
   ├── mongo # (2)!
   ├── ssl # (3)!
├── docs # (4)!
├── manifests # (5)!
   ├── k8s # (6)!
      ├── deploy.template.yaml # (7)!
├── perf # (8)!
├── src # (9)!
├── tests # (10)!
├── tools # (11)!
   ├── postman # (12)!
├── .vscode # (13)!
├── .editorconfig # (14)!
├── .gitignore # (15)!
├── .gitlab-ci.yml # (16)!
├── .hadolint.yaml # (17)!
├── .pre-commit-config.yaml # (18)!
├── .pylintrc # (19)!
├── .pyproject.toml # (20)!
├── docker-compose.yml # (21)!
├── Dockerfile # (22)!
├── Makefile # (23)!
├── README.md # (24)!
├── requirements-dev.txt # (25)!
├── requirements.txt # (26)!
├── setup.cfg # (27)!
└── sonar-project.properties # (28)!
  1. Diretório que contém os arquivos utilizados no processo de construção da imagem Docker ⧉ do projeto.
  2. Arquivos .js com instruções que podem ser aplicadas no banco de dados MongoDB
  3. Diretório com os certificados necessários para estabelecer conexões TLS com os serviços
  4. Arquivos complementares (markdown, imagens, css, etc...) à documentação do projeto
  5. Diretório contendo os arquivos de configuração aplicados nos ambientes (Infrastructure as Code) durante a implantação da aplicação.
  6. Este diretório contém os arquivos .yaml aplicados no cluster Kubernetes ⧉ provisionado na nuvem.
  7. Esse arquivo .yaml é utilizado para implantar a aplicação no cluster Kubernetes, definindo a imagem Docker, as variáveis de ambiente, o número de réplicas e o mecanismo de redimensionamento com base na demanda. Essa configuração é realizada por meio dos recursos Deployment ⧉, Service ⧉ e HorizontalPodAutoscaler ⧉ disponibilizados pela API do Kubernetes.
  8. Contém o código-fonte para execução do teste de carga da aplicação
  9. Contém o código-fonte e recursos que se tornam parte do pacote publicado
  10. Contém todo o código de teste para o projeto
  11. Diretório com ferramentas (scripts) auxiliares a manutenção do projeto
  12. Contém o arquivo .json exportado a partir da ferramenta Postman com os endpoints do projeto
  13. Diretório com as configurações utilizadas pelo VS Code no projeto
  14. Ajuda a manter estilos de codificação consistentes entres os desenvolvedores (importar na IDE)
  15. Permite ignorar qualquer arquivo que ainda não é rastreável no Git
  16. Configuração do pipeline CI/CD no GitlabCI
  17. Define as regras aplicadas durante a execução do lint no Dockerfile
  18. Arquivo de configuração da ferramenta pre-commit que descreve quais repositórios e hooks estão instalados
  19. Configura as regras aplicadas durante a execução do lint no código-fonte *.py
  20. Arquivo (formato PEP 518) que contém os requisitos de sistema para compilação do projeto
  21. Define os serviços (Mongo, Redis, RabbitMQ, etc) consumidos pela aplicação (útil para testar localmente)
  22. Contém todos os comandos necessários para construir a imagem docker da aplicação
  23. Utilitário para facilitar a execução de scripts usados na manutenção do projeto
  24. Página de documentação do projeto (escrito com 'Markdown')
  25. Descreve as dependências que precisam ser instaladas em modo 'desenvolvimento'
  26. Descreve as dependências que precisam ser instaladas em modo 'produção'
  27. Arquivo de configuração utilizado na instalação da aplicação como pacote python
  28. Define os parâmetros utilizados na análise do código através da ferramenta Sonar
.
├── apache # (1)!
├── CHANGELOG.md # (34)!
├── db # (2)!
├── dist # (3)!
├── docs # (4)!
├── e2e # (5)!
├── manifests # (6)!
   ├── k8s # (7)!
       ├── deploy.template.yaml # (8)!
├── nginx # (9)!
├── node_modules # (10)!
├── src # (11)!
├── .gitlab # (12)!
├── .vscode # (13)!
├── angular.json # (14)!
├── browserslist # (15)!
├── commitlint.config.js # (16)!
├── Dockerfile # (17)!
├── json-server.js # (18)!
├── karma.conf.js # (19)!
├── LICENSE # (20)!
├── package.json # (21)!
├── README.md # (22)!
├── tsconfig.json # (23)!
├── tsconfig.app.json # (24)!
├── tsconfig.spec.json # (25)!
├── tslint.json # (26)!
├── yarn.lock # (27)!
├── .dockerignore # (28)!
├── .editorconfig # (29)!
├── .gitignore # (30)!
├── .gitlab-ci.yml # (31)!
├── .prettierignore # (32)!
└── .prettierrc.json # (33)!
  1. Possui as configurações para iniciar o servidor HTTP Apache (permite simular o service worker)
  2. Diretório com todos os arquivos .json carregados pela ferramenta JSON Server (simulador API Rest)
  3. Contém os artefatos gerados durante a execução do processo de build e test
  4. Arquivos complementares (markdown, imagens, css, etc...) à documentação do projeto
  5. Diretório com o código-fonte dos testes "end to end"
  6. Diretório contendo os arquivos de configuração aplicados nos ambientes (Infrastructure as Code) durante a implantação da aplicação.
  7. Este diretório contém os arquivos .yaml aplicados no cluster Kubernetes ⧉ provisionado na nuvem.
  8. Esse arquivo .yaml é utilizado para implantar a aplicação no cluster Kubernetes, definindo a imagem Docker, as variáveis de ambiente, o número de réplicas e o mecanismo de redimensionamento com base na demanda. Essa configuração é realizada por meio dos recursos Deployment ⧉, Service ⧉ e HorizontalPodAutoscaler ⧉ disponibilizados pela API do Kubernetes.
  9. Possui as configurações do servidor HTTP NGinx (usada na construção da imagem Docker)
  10. Dependências do projeto (baixadas após execução do yarn install)
  11. Código-fonte do projeto (.ts, .html, .scss, etc...). Mais detalhes em https://angular.io/guide/file-structure ⧉
  12. Diretório com templates markdown para uso no GitLab Web como template
  13. Diretório com as configurações utilizadas pelo VS Code no projeto
  14. Arquivo de configuração do Angular CLI
  15. Configura a lista de navegadores e versões suportadas pela aplicação
  16. Arquivo de configuração que permite customizar o uso da ferramenta Commitlint
  17. Contém todos os comandos necessários para construção da imagem docker contendo os cenários
  18. Configuração do servidor JSON que simula uma API Rest (permite prosseguir com a atividade sem o backend)
  19. Arquivo de configuração do executor de testes Karma (https://karma-runner.github.io/ ⧉)
  20. Arquivo com a licença do projeto (usado apenas para remover o warning durante o processo de build)
  21. Descreve as informações e dependências necessárias para o funcionamento do projeto
  22. Página de documentação do projeto (escrito com 'Markdown')
  23. Configuração utilizada pelo compilador TypeScript (compartilhado com a aplicação e testes)
  24. Configuração utilizada pelo compilador TypeScript para os arquivos da aplicação
  25. Configuração utilizada pelo compilador TypeScript para os arquivos de testes
  26. Define as regras aplicadas durante a execução do lint na aplicação
  27. Lockfile utilizado para congelar a estrutura de diretórios do node_modules (gerado automaticamente)
  28. Contém os arquivos e diretórios que devem ser ignorados pela ferramenta Docker
  29. Ajuda a manter estilos de codificação consistentes entres os desenvolvedores (importar na IDE)
  30. Permite ignorar qualquer arquivo que ainda não é rastreável no Git
  31. Configuração do pipeline CI/CD no GitlabCI
  32. Permite ignorar arquivo para formatação através da biblioteca Prettier
  33. Arquivo de configuração que permite customizar a formatação do código-fonte pela biblioteca Prettier
  34. Arquivo contendo as melhorias e correções realizadas em cada versão do projeto
.
    ├── src 
     ├── @types.tsx # (1)!
     ├── assets recursos # (2)!
     ├── components # (3)! 
      ├── NomeComponente # (4)! 
       ├── index.tsx # (5)! 
       ├── nomeComponente.tsx # (6)! 
       ├── @types.tsx # (7)! 
       └── styles.tsx # (8)! 
      ├── NomeComponenteComplexos # (9)! 
       ├── index.tsx # (10)! 
       ├── @types.tsx # (11)! 
       ├── NomeComponenteRoot.tsx # (12)! 
       ├── nomeComponentente # (13)!
        ├── index.tsx # (14)! 
        ├── nomeComponente.tsx # (15)!
        ├── @types.tsx # (16)! 
        └── styles.tsx # (17)! 
      └── ComponentesAgrupados # (18)! 
      ├──nomeComponentente # (19)! 
       ├── index.tsx # (20)!
       ├── nomeComponente.tsx # (21)!
       ├── @types.tsx # (22)!
       └── styles.tsx # (23)!
      ├── @types.tsx # (24)!
      ├── NomeComponenteRoot.tsx # (25)!
      └── index.tsx # (26)!
     ├── helpers # (27)!
      ├── index.tsx # (28)! 
      └── nomeFuncaotsx # (29)! 
     ├── hooks # (30)!
      ├── index.tsx # (31)! 
      └── nomeHook.tsx # (32)! 
     ├── pages páginas # (33)! 
      └──NomePagina # (34)! 
      ├── @types.tsx # (35)! 
      ├── index.tsx # (36)! 
      ├── nomePagina.tsx # (37)! 
      ├── routes.tsx # (38)! 
      └── subPagina # (39)! 
      ├── @types.tsx # (40)! 
      ├── index.tsx # (41)! 
      ├── nomePagina.tsx # (42)! 
      └── routes.tsx # (43)! 
     ├── routes # (44)! 
      ├── index.tsx # (45)!
      └── useRouter.tsx # (46)! 
     ├── storeds # (47)! 
      ├── index.tsx # (48)! 
      └── nomeStoreds # (49)! 
       ├── index.tsx # (50)! 
       └── nomeStoreds.tsx # (51)! 
     ├── theme # (52)! 
      ├── index.tsx # (53)! 
      └── nomeStoreds.tsx # (54)! 
    ├── main.tsx # (55)! 
    └── App.tsx # (56)! 
  1. contém os types globais do projeto
  2. estáticos como imagens, ícones, etc
  3. componentes reutilizáveis
  4. pasta do componente
  5. contém exportações da pasta
  6. componente
  7. contém os types do componente
  8. contém um objeto em CssJs estilizado par ao material ui
  9. pasta de componentes complexos
  10. contém exportações da pasta
  11. contém os types do componentes
  12. componente principal
  13. nome do componente
  14. contém exportações da pasta
  15. componente
  16. contém os types do componente
  17. contém um objeto em CssJs estilizado par ao material ui
  18. pasta de componentes agrupados
  19. nome do componente
  20. contém exportações da pasta
  21. componente
  22. contém os types do componente
  23. contém um objeto em CssJs estilizado par ao material ui
  24. contém os types do componente
  25. recursos estáticos como imagens, ícones, etc
  26. contém exportações da pasta
  27. funções auxiliares
  28. contém exportações da pasta
  29. um arquivo para cada função
  30. hooks customizados
  31. contém exportações da pasta
  32. um arquivo para cada hook custom
  33. pages da aplicação
  34. pasta com o nome da página
  35. contém type da pasta
  36. contém index com a exportação da page
  37. componente que monta a página
  38. arquivo que exporta as rotas
  39. caso seu projeto tenha pagina alinhadas
  40. contém type da pasta
  41. contém index com a exportação da page
  42. componente que monta a página
  43. arquivo que exporta as rotas
  44. definição de rotas
  45. contém exportações da pasta
  46. hook que é responsavel por importar rotas cadastrar-las no router dom
  47. gerenciamento de estado global
  48. contém exportações da pasta
  49. uma pasta para cada estado global
  50. contém exportações da pasta
  51. arquivo contendo do zustand estado global
  52. configuração e estilos do tema
  53. contém exportações da pasta
  54. um arquivo para cada estado global
  55. arquivo de entrada principal
  56. componente raiz da aplicação