Arquitetura selecionada
Hexagonal
A arquitetura hexagonal no frontend coloca regras e casos de uso no centro, enquanto componentes, HTTP, storage e bibliotecas externas ficam como adaptadores. A interface consome portas, não implementações concretas.
Estrutura de pastas
Navegue pelos arquivos para ver como a arquitetura aparece no código.
export class Cart {
add(item: CartItem) {
return new Cart([...this.items, item]);
}
}Prós
- Protege regras de negócio contra detalhes de UI e infraestrutura.
- Facilita testes de casos de uso sem Angular, DOM ou HTTP.
- Ajuda quando o frontend tem lógica rica e integrações variadas.
Contras
- Cria mais arquivos e conceitos do que um CRUD simples precisa.
- Exige disciplina para componentes não pularem direto para adaptadores.
- Pode parecer abstrata demais para times iniciantes.
Quando usar
- Frontends com regras de negócio importantes.
- Aplicações que precisam trocar fontes de dados ou integrações.
- Produtos onde testes de domínio trazem valor real.
Exemplo real
Um checkout com regras locais de carrinho, cupons, estoque e múltiplos adaptadores de pagamento.
Cenário prático
A regra de aplicar cupom fica no domínio, enquanto o adaptador HTTP apenas traduz chamadas para a API de promoções.
Como implementar
- Modele portas para operações que o domínio precisa executar.
- Implemente adaptadores para HTTP, storage, analytics ou SDKs externos.
- Faça componentes dependerem de casos de uso, não diretamente de clientes de infraestrutura.
Cuidado comum
Criar portas para qualquer detalhe pequeno deixa a arquitetura burocrática e difícil de navegar.