DEV Community

Erick Gabriel dos Santos Alves
Erick Gabriel dos Santos Alves

Posted on

Migrando um YMS de 5 anos: Do Angular 16 ao 21 (Parte 7) - Clean Architecture: A nova estrutura de pastas por domínios

#angular #typescript #frontend #braziliandevs

Fala, comunidade dev! 👋

Nas últimas 6 partes dessa série, mergulhamos fundo no código: Standalone Components, Rotas, Signals e Zoneless. Mas refatorar a arquitetura técnica sem arrumar a "casa" (a estrutura de pastas) é colocar motor de Ferrari em chassi de fusca.

Um projeto de 5 anos geralmente sofre do mesmo mal genérico de organização, e hoje vou mostrar como aplicamos conceitos de Clean Architecture e Domain-Driven Design (DDD) no Front-end para salvar a manutenção do nosso YMS (Yard Management System).

1. O Erro Clássico: Organização por Tipo Técnico

Lá no Angular 14/16, a literatura (e as ferramentas de CLI) nos ensinava a agrupar arquivos pelo que eles eram, e não pelo que eles faziam. A estrutura clássica de um sistema parecia assim:

src/app/
 ├── components/ (misturava botões com painéis de negócio)
 ├── models/     (centenas de interfaces jogadas aqui)
 ├── services/   (tudo que era API ficava aqui)
 └── views/      (as páginas em si)
Enter fullscreen mode Exit fullscreen mode

O Pesadelo Cognitivo: Para alterar a tela de "Agendamento", o desenvolvedor precisava abrir a pasta de views para achar o HTML, depois pular para a pasta de models para entender a interface, e depois caçar a chamada de API na pasta de services. O código que mudava junto morava em bairros completamente diferentes do projeto.

2. A Virada: Estrutura Orientada a Domínios (Features)

Na migração para o Angular 21, pivotamos a arquitetura para domínios de negócio. A regra de ouro virou: se o código muda junto, ele deve morar junto.

Nossa nova arquitetura isola responsabilidades. O módulo (agora Standalone) de balanca não faz a menor ideia do que acontece dentro de agendamento.

src/app/
 ├── core/       (Interceptors, Auth, Guards - estritamente técnico e Singleton)
 ├── shared/     (Botões, Pipes, componentes UI "burros" e reaproveitáveis)
 └── features/   (Os Domínios do Negócio)
      ├── agendamento/
      │    ├── models/
      │    ├── services/
      │    └── components/
      ├── balanca/
      │    ├── models/
      │    ├── services/
      │    └── components/
Enter fullscreen mode Exit fullscreen mode

3. Por que isso muda o jogo?

Organizar arquivos pode parecer preciosismo estético, mas em bases de código maduras e sistemas Enterprise, é a linha tênue entre entregar uma feature em 2 horas ou em 2 dias.

  • Onboarding rápido: Um desenvolvedor júnior entra no time hoje para arrumar um bug na tela da Balança. Ele abre a pasta features/balanca e absolutamente tudo que ele precisa para entender aquele contexto está lá dentro.
  • Escalabilidade e Desacoplamento: Se o negócio crescer absurdamente, nós podemos extrair a pasta balanca inteira e transformá-la em uma biblioteca independente (Angular Workspace/Nx) ou até mesmo em um Micro-frontend sem esforço, pois ela não compartilha "lixo" com outros domínios.

Conclusão

Ter um código moderno usando Signals e rodando sem o zone.js é maravilhoso, mas é a arquitetura de pastas que dita a velocidade e a sanidade mental do time no longo prazo.

No próximo post (Parte 8), vamos abordar um desafio Enterprise raiz que costuma dar muita dor de cabeça em sistemas legados: a Internacionalização de dados e traduções dinâmicas.

E como está a pasta src/app dos projetos de vocês hoje? Mais parecida com o primeiro modelo (técnico) ou com o segundo modelo (orientado a domínio)? Comentem aí! 👇

Top comments (0)