Fabio Gouw

No post anterior, eu comecei a construção de uma aplicação que une os conceitos do Clean Architecture e o Actor Model. Entretanto, ela ainda não tratava vários aspectos essenciais para uma aplicação ser considerada resiliente. Agora nesse segundo artigo, eu vou mostrar uma proposta para tratar a idempotência na aplicação, de forma com que possamos lidar com cenários de reprocessamento de mensagens com segurança. O código resultante está disponível em  https://github.com/fabiogouw/OrleansBank/tree/3283d13eea84da34b8a7131c63cdc1ad8d186f63 O problema Um problema que meu exemplo no post anterior trazia era que, caso houvesse um erro no processamento do débito e no crédito da transferência bancária, simplesmente as contas ficariam com seu estado inconsistente. Por exemplo, a conta debitada teria o dinheiro retirado, mas a conta que era para ser creditada nunca receberia esse valor. Isso numa aplicação no mundo real é inconcebível. Uma possibilidade para corrigir esse comportamento aqui ser

Hoje eu trago uma proposta de artigo que é um exercício onde juntei dois conceitos bem legais no desenvolvimento de software: a arquitetura no estilo Clean Architecture e o modelo de atores! Eu pensei em escrever esse artigo baseado num estudo de como utilizar esses dois assuntos que eu fiz e que está disponível no meu GitHub:  https://github.com/fabiogouw/OrleansBank   Minha proposta é que este seja o primeiro artigo de uma série onde eu vou evoluindo essa aplicação de exemplo, melhorando o código e resolvendo problemas que vão surgindo, sejam eles técnicos ou mesmo conceituais. Benefícios e premissas Antes de seguirmos com este exercício, faz sentido relembrarmos os benefícios e premissas do clean architecture e do modelo de atores. Também vale citar que não são conceitos que se excluem, são coisas bem diferentes! Por que Clean Architecture? Os modelos de arquitetura como o Clean Architecture, do Uncle Bob, o Hexagonal, do Alistair Cockburn ou o Onion do Jeffrey Palermo seguem todos