Como estruturar sua aplicação Angular?

Ao iniciarmos o desenvolvimento de uma aplicação web, uma das perguntas que vem em nossas cabeças é "Como montar um estrutura ou arquitetura de projeto que seja escalonava e sustentável?".

Para uma aplicação pequena, a estrutura padrão gerada pelo Angula CLI é adequada. Ainda assim, quando seu projeto crescer, você notará a dificuldade em manter e dimensionar sua aplicação corretamente.

Esse artigo é para compartilhar um pouco de como estruturo minhas aplicações em Angular na busca pela flexibilidade, escalabilidade e performance. Para nos ajudar nesse processo vamos pensar em uma aplicação para disponibilizar cursos on-line de Pós-graduação, MBA e Certificações.

Nessa nossa primeira entrega nossa aplicação terá uma página de divulgação dos cursos por categorias e páginas com o detalhe dos cursos.

Sabemos que um aplicação Angular é composto por diversos elementos como módulos, componentes, templates e serviços. Já sabendo qual o contexto do nosso projeto então vamos montar uma estrutura por camadas. A imagem a seguir dá uma melhor visibilidade de como funcionará as interações entre módulo e a API.

Figura 1 - Arquitetura de software demonstrando interações entre módulos e Api

Como seria nossa estrutura de pastas do nosso projeto pensando na escalabilidade?

Figura 2 - Estrutura de diretório

• Core: Arquivos essenciais para a aplicação;

• Shared: onde ficarão os Dumb Components, que são componentes que não fazem nada por conta própria;

• Pages: São as páginas do nosso projeto onde estarão disponível os Smart Components.

Core: nesse diretório ficarão disponíveis os serviços singleton, tokens de injeção, constantes, configurações da aplicação, pipes, interceptors, guards, auth, service, utils. etc. São arquivos que serão usados em toda aplicação. Se conter algo que seja específico para a própria aplicação, implementação, CI/CD e API então colocamos no Core.

Shared: considere os módulos compartilhados como uma mini-biblioteca para seus componentes de IU. Eles não são específicos para um único recurso de negócios. Eles devem ser Dumb Components onde você possa pegá-los e colocar em outro projeto angular que funcione, não esquecendo que neste caso, as dependências sejam atendidas.

Um alerta para nosso SharedModule é que devemos ficar atentos em não deixá-lo gigantesco.Para evitar que isso ocorra é granularizar pensando em uma metodologia "Atomic Design" ou "Design Atômico" com a intenção de deixar caracterizada como um mini-biblioteca personalizada.

Pages: o diretório de páginas é a parte mais interessante dessa nossa arquitetura. Vamos pensar como uma "sink" ou um funil, onde os módulos de recursos caem, mas nada sai ou seja, nada exportado. As controllers não terão lógica de negócios. Eles são meramente apresentador e orquestrador do componentes dos módulos de recursos de negócio.

Vamos para nossa página inicial. Ele conterá um cabeçalho, rodapé e a relação de cursos. Esses componentes será compartilhada pelo SharedModule. Todos provenientes dos respectivos módulos.

  @NgModule ({
    declarations: [HomeComponent],
    imports: [
      CommonModule,
      SharedModule,
      HomeRoutingModule,
    ],
  })
  export class HomeModule {}

SharedModule onde compartilhamos nossa mini-biblioteca que consta os nossos componentes Header, List e Footer.

  @NgModule ({
    declarations: [      
      FooterModule,
      HeaderModule,
      ListModule,
    ],
    imports: [
      CommonModule,
      RouterModule,
      FormsModule,
      ReactiveFormsModule,
      NgbModule,
    ],
    exports: [ 
      FooterModule,
      HeaderModule,
      ListModule,
    ],
  })
  export class SharedModule {}

Como seria essa estrutura da home.component.html fictícia ?

 <!-- Componente do Header -->
  <app-header> </app-header>

  <main class="container">

    <!-- Componente do List -->
    <app-list> </app-list>

  </main>


    <!-- Componente do Footer -->
    <app-footer> </app-footer>

Não podemos esquecer do serviço que irá alimentar com os dados do cursos disponíveis. Esse serviço irá ser chamado na página home.component.ts.

import { Component, OnInit, OnDestroy } from '@angular/core';
import { Subscription } from 'rxjs';
import { CoursesService } from '../../core/services/courses.service';

@Component({
  selector: 'app-home',
  templateUrl: './home.component.html',
  styleUrls: ['./home.component.css'],
})
export class DashboardComponent implements OnInit, OnDestroy {

  private subscriptions = new Subscription()

  constructor(private service: CoursesService) {}

  ngOnInit(): void {}

  ngOnDestroy(): void {
      this.subscriptions.unsubscribe()
  }
}

Até o momento os códigos descrito acima são apenas uma esboço da nossa aplicação para demonstrar a organização da nossa arquitetura modular. Conforme novos temas de artigos forem surgindo irei evoluindo o código desse nosso projeto fictício.

A ideia desse artigo é para ajudar quem está iniciando ou tem dificuldade em montar uma boa arquitetura. Esse artigo te ajudou para ter uma ideia de como organizar seu projeto?

Espero que sim e desde já agradeço pela sua leitura e caso queira o exemplo desse código e acompanhar sua evolução basta acessar o meu git [https://github.com/Godoi/course-portal]