Estrutura projeto Angular: guia de pastas em 5 passos

Organizar pastas em um projeto Angular não é tarefa de fim de semana. É decisão de arquitetura que acompanha o código por anos. Quem já herdou um projeto com 40 componentes soltos na pasta app sabe o caos que isso gera. A boa notícia: existe um padrão consolidado pela comunidade, o core/features/shared, que separa responsabilidades e prepara a aplicação para crescer sem reescritas dolorosas.

Este guia mostra, em 5 passos, como estruturar pastas em um projeto Angular usando esse modelo. O resultado esperado: uma base de código previsível, onde qualquer desenvolvedor encontra o que precisa sem perguntar no grupo. Pré-requisitos: Angular CLI instalado e um projeto criado com ng new. Nenhuma configuração extra é necessária.

Passo 1: Entenda o papel de cada pasta raiz

Antes de criar pastas, entenda o que cada uma representa. A pasta core é o núcleo da aplicação: serviços singleton, guards, interceptors e modelos usados uma única vez. A pasta features agrupa módulos por funcionalidade (login, dashboard, checkout). A pasta shared concentra componentes, diretivas e pipes reutilizáveis entre features.

Dica: mantenha core enxuta. Se um serviço é usado por apenas uma feature, ele pertence àquela feature, não ao core.

Erro comum: colocar tudo em shared como se fosse uma gaveta de objetos perdidos. Isso transforma a pasta num depósito sem critério.

Passo 2: Crie a estrutura base com Angular CLI

Use o Angular CLI para gerar a estrutura. Dentro de src/app, crie as pastas core, features e shared. Para cada feature, use ng generate module features/nome-da-feature --routing. Isso cria o módulo com rota própria, evitando configuração manual.

ng generate module features/dashboard --routing ng generate module features/login --routing ng generate component features/dashboard/dashboard-home

Dica: nomeie features no singular (feature, não features) para evitar confusão com a pasta raiz.

Erro comum: criar módulos sem --routing e depois emendar rotas no módulo raiz, o que infla o AppModule.

Passo 3: Popule o core com serviços e guards

O core deve conter o que é carregado uma única vez: AuthService, ApiService, guards de rota, interceptors HTTP. Crie subpastas por tipo: core/services, core/guards, core/interceptors. Assim, a localização de um arquivo revela sua função.

ng generate service core/services/auth ng generate guard core/guards/auth

Dica: exporte o core como um módulo CoreModule e importe-o apenas no AppModule. Isso garante que serviços singleton não sejam recriados em lazy loading.

Erro comum: importar CoreModule em vários módulos, quebrando o singleton e gerando múltiplas instâncias de serviço.

Passo 4: Organize features por funcionalidade

Cada feature é uma ilha autônoma: módulo, rotas, componentes, serviços e modelos próprios. Dentro de features/dashboard, por exemplo, crie dashboard-home, dashboard-stats e um serviço dashboard.service.ts. Nada que pertence ao dashboard vaza para fora.

ng generate component features/dashboard/dashboard-stats ng generate service features/dashboard/dashboard

Dica: use lazy loading nas rotas de cada feature. Isso reduz o bundle inicial e melhora o tempo de carregamento.

Erro comum: criar componentes no nível de app e depois importá-los em features, criando dependências cruzadas.

Passo 5: Centralize o reutilizável em shared

O shared guarda o que é genuinamente reutilizável: um botão customizado, um pipe de formatação de data, uma diretiva de máscara. Crie subpastas por tipo: shared/components, shared/pipes, shared/directives. Exporte tudo via SharedModule.

ng generate component shared/components/button ng generate pipe shared/pipes/format-date

Dica: antes de colocar algo em shared, pergunte: "isso será usado em pelo menos duas features?" Se não, fica onde está.

Erro comum: colocar um componente que só o dashboard usa em shared, poluindo o módulo e aumentando o bundle de quem importa.

Checklist rápido

• [ ] Pastas core, features e shared criadas em src/app
• [ ] CoreModule importado apenas no AppModule
• [ ] Cada feature com módulo e rota própria (lazy loading)
• [ ] Serviços e guards do core em subpastas por tipo
• [ ] Componentes reutilizáveis em shared com SharedModule exportando-os
• [ ] Nenhum componente solto na raiz de app

FAQ

Qual a diferença entre core e shared?

Core contém serviços e guards de uso único, carregados uma vez na aplicação. Shared guarda componentes, pipes e diretivas reutilizáveis entre features. A regra prática: se é instanciado uma vez, vai para core; se é usado em vários lugares, vai para shared.

Posso usar essa estrutura em projetos pequenos?

Sim, mas com moderação. Em projetos de um ou dois módulos, a estrutura pode parecer excessiva. Ela brilha quando o time cresce e as funcionalidades se multiplicam. Para projetos pequenos, um shared e uma pasta features simples já resolvem.

O que fazer com a pasta app raiz?

A pasta app deve conter apenas o AppModule, o AppComponent e talvez um app-routing.module.ts. Todo o resto vai para core, features ou shared. Se o app tiver mais que isso, é sinal de que a estrutura não está sendo seguida.

E se eu já tenho um projeto bagunçado?

Refatorar tudo de uma vez é arriscado. Comece movendo os componentes de app para features ou shared, uma feature por vez. Use o checklist acima como guia. A migração incremental reduz o risco de quebrar funcionalidades existentes.

Essa estrutura é padrão oficial do Angular?

Não é oficial, mas é amplamente adotada pela comunidade. A documentação do Angular sugere organização por funcionalidade, e o padrão core/features/shared é uma evolução prática desse princípio. O importante é ter um critério claro e consistente.