Arquitetura selecionada
Domain Driven Frontend
Inspirada em DDD, essa abordagem organiza o código por domínios e contextos. Cada domínio preserva sua linguagem, regras, casos de uso e integrações com a interface.
Estrutura de pastas
Navegue pelos arquivos para ver como a arquitetura aparece no código.
export class Customer {
constructor(
readonly id: CustomerId,
readonly document: TaxDocument,
) {}
canReceiveInvoice() {
return this.document.isValid();
}
}Prós
- Mantém o código próximo da linguagem do negócio.
- Ajuda a lidar com regras complexas e evolução de produto.
- Cria limites claros entre contextos diferentes.
Contras
- Pode ser excessiva para sistemas simples.
- Requer bom entendimento do domínio e alinhamento com backend/produto.
- A curva de aprendizado é maior.
Quando usar
- Produtos com regras de negócio ricas ou sensíveis.
- Sistemas que precisam evoluir por domínios independentes.
- Times que já discutem bounded contexts, entidades e casos de uso.
Exemplo real
Uma plataforma financeira com domínios de conta, cobrança, assinatura, risco e compliance.
Cenário prático
O domínio `billing` concentra termos como fatura, vencimento, inadimplência e pagamento, enquanto `subscription` cuida de plano, ciclo e renovação.
Como implementar
- Mapeie contextos de negócio antes de criar pastas.
- Use nomes do domínio nos arquivos, não apenas nomes técnicos.
- Evite dependências diretas entre domínios; quando necessário, crie contratos explícitos.
Cuidado comum
Aplicar DDD só como nomes de pasta, sem modelar regras e linguagem do negócio, cria complexidade sem benefício.