Como definir uma estrutura de pastas altamente escalável para o seu projeto Angular

Leandro Mancini
5 min readJun 11, 2019

--

Encontrar uma estrutura de pastas adequada para meus aplicativos Angular é algo com o qual tenho lutado por um longo tempo. Isso se tornou um problema real no meu primeiro projeto Angular , especialmente quando o aplicativo cresceu em tamanho. Acabei adicionando continuamente novos recursos sem estrutura. Isso dificultou a localização de arquivos e a realização de alterações adicionais na estrutura de pastas e isso se tornou demorado o desenvolvimento. Mas eu entendi muito bem sobre o que fazer e o que não fazer ao estruturar um aplicativo Angular.

O objetivo deste artigo é ajudar outros desenvolvedores em uma situação semelhante.

Estruturando o projeto

Se você já leu sobre a criação de aplicativos com o padrão Arquitetura Limpa, deverá definitivamente ter visto o diagrama a seguir que explica a estrutura geral.

As práticas usadas neste artigo são muito aplicáveis ​​ao meu caso de uso único e não devem, de forma alguma, ser rigorosamente seguidas. A estrutura de pastas de um projeto será alterada com base em uma ampla gama de fatores. Mas, se você estiver interessado em uma estrutura que foque em uma arquitetura de vários módulos com um grande foco no dimensionamento, continue lendo.

Nota! O [+] indica que a pasta possui arquivos adicionais.

| - app
| - core
| - domain
| - [+] entities
| - interfaces
| - [+] controllers
| - [+] entities
| - [+] mensagens
| - [+] repositories
| - [+] usecases
| - [+] validations
| - [+] usecases
| - core.module.ts
| - data
| - [+] repository
| - data.module.ts
| - infra
| - [+] authentication
| - [+] http
| - [+] log
| - [+] translations
| - infra.module.ts
| - presentation
| - [+] base
| - [+] controllers
| - [+] pages
| - [+] shared
| - presentation.module.ts

As principais diretrizes que realmente se destacaram para mim foram “estruturar o aplicativo de forma que você possa localizar o código rapidamente” e “ter uma visão de curto prazo da implementação e uma visão de longo prazo. Comece pequeno, mas tenha em mente onde o aplicativo está indo pela estrada”.

  1. Core: A camada principal é onde definimos as entidades centrais, casos de uso, recursos para traduções de textos e definições de interface.
  2. Data: Essa camada lida com a implementação das interfaces de dados que estão na camada principal (core).
  3. Infra: A camada de Infraestrutura contém configurações do aplicativo e outros valores predefinidos.
  4. Presentation: A camada de apresentação contém a estrutura angular clássica com componentes e visualizações, como você já os conhece.

O módulo principal

Domain

As entidades deste aplicativo são mantidas muito simples, onde declaramos os parâmetros e os tipos.

Exemplo: Um UsuarioModel contém o nome do usuário, seu sobrenome e uma data para seu aniversário.

export class UsuarioModel {   nome: string;
sobrenome: string;
aniversario: Date;
}

Interfaces

A camada de interface faz a comunicação entre cada uma dessas camadas ela é definida por interfaces, permitindo que as camadas de entrada e saída sejam facilmente reproduzidas.

export interface IUsuarioUseCase<S, T> {
obter(params: S): Observable<T>;
inserir(params: S): Observable<T>;
alterar(params: S): Observable<T>;
excluir(params: number): Observable<T>;
}

Usecases

A camada usecases implementa toda a lógica de negócio do aplicativo. O objetivo dos Casos de Uso é solicitar dados aos repositórios e transformá-los em algo utilizável para a camada presentation. É aqui que iremos validar se o que estamos pedindo está válido ou não.

O módulo Dados

Repository

A camada do repositório consiste em três classes:

O repositório que implementa a interface do repositório definida na camada principal (core).

A entidade que o repositório precisa para gerenciar e trabalhar com os dados no nível da API.

Um mapeador que converte os objetos de dados da representação da camada de dados na representação da entidade principal. Estou usando a biblioteca AutoMapper que nos facilita esse de para.

O módulo Infraestrutura

Authentication

A camada authentication simplesmente lida com o ciclo de autenticação do usuário (do login ao logout).

| - authentication 
| - authentication.service.ts | spec.ts

Http

A camada http é uma classe de interceptor que considero especialmente útil. Isso nos permite capturar e modificar as solicitações e respostas de nossas chamadas de API.

| - http
| http-interceptor.ts | spec.ts

Log

A camada log é onde podemos classificar amplamente tipos de log nas seguintes categorias.

  1. Erro
  2. Informação
  3. Depurar
  4. Aviso

Translations

A camada translations é algo bem simples que usa a biblioteca ngx-translate para gerenciar traduções em um aplicativo angular.

O módulo apresentação

Base

O BaseModulecontém os arquivos componentes globais, usados ​​estaticamente em todo o aplicativo. Esses arquivos aparecerão em todas as páginas do aplicativo após o login.

Controllers

Os controllers lembram o que chamamos de “code-behind”. O Controlador é altamente dependente da Visualização. Na maioria das implementações do framework, ele é criado até mesmo pela View (como é o caso, por exemplo, do ng-controller em Angular).

Pages

O PagesModulecontém os arquivos de páginas. No entanto, em Angular, uma página é um componente ou, pelo menos, uma coleção de componentes. Em nosso site, temos muito o conceito de navegar para determinadas páginas. Em outros aplicativos angulares, isso quase certamente não seria o caso. Então, eu estava interessado em trazer a ideia de páginas para clarear a pasta de componentes.

Shared

O SharedModuleé onde quaisquer componentes / filtros e serviços compartilhados devem ir. O sharedModulepode ser importado em qualquer outro módulo quando esses itens forem reutilizados. O módulo compartilhado não deve ter nenhuma dependência do restante do aplicativo e, portanto, não deve depender de nenhum outro módulo.

Resumo

Em conclusão, não há nenhum plano quando se trata de criar uma estrutura de pastas em Angular. A estrutura vai mudar muito dependendo do projeto em que você está trabalhando. Este artigo aborda um caso de uso explícito usando vários módulos, que por sua vez são divididos em páginas e um conjunto compartilhado de componentes.

--

--