Proponho uma arquitetura de eventos para a tela de investigação de casos. Atualmente, qualquer alteração nessa tela exige que o time que mantém o motor de aprovação modifique vários serviços simultaneamente, o que torna o deploy arriscado e lento. Com um barramento de eventos, cada serviço poderia reagir de forma independente às mudanças de estado, reduzindo o acoplamento e o tempo de entrega. Além disso, isso facilitaria a rastreabilidade de cada decisão tomada no fluxo de análise.
Conta em Crédito × Disponibilidade e Performance, visão “Onde há oportunidade”.
Como a área foi escolhida
- Antifraude 82%
- Motor de Decisão 17%
- Nenhum destes 1%
e mais 22 com probabilidade menor.
Relato cruzado: quem relata é do time Motor de Decisão e o objeto é do time Antifraude, da mesma área (Crédito).
| Dimensão | Resposta | Confiança | Alternativas |
|---|---|---|---|
| Área | Crédito › Antifraude | 99% |
|
| Frente | Disponibilidade e Performance › Gargalo de Escalabilidade encaixe fraco | 61% |
|
| Natureza | Proativo | 100% | |
| Severidade | 0,44 Nível 1 (nível 2 de 4) não vale para esta natureza | 64% | |
| Impacto esperado | 0,67 Nível 2 (nível 3 de 4) | 100% | |
| Causa raiz | Arquitetura Inadequada | 100% | |
| Urgência | 0,11 | sem confiança | |
| Problema | Sem problema | 50% |