Olá Otávio! Eu gosto muito de microservico principalmente dirigido a eventos porém tenho dificuldade em documentar esse serviço como faço por exemplo com rest api através do swagger. Se pode fazer um vídeo falando sobre documentação de microservico dirigido a eventos.
Um ponto muito importante quando se trabalha com event driven é a “Idempotência”, principalmente em domínios que envolvem transação financeira. Pensar em reprocessar eventos sem ter Idempotência bem implementado é um problema grave. E também ter um mecanismo de retry é imprescindível. Então junto com Event Driven é legal pensar em Idempotência junto com Inbox e Outbox.
Interessante eu fico vendo o que pode dar errado é ter que fazer um “rollback” ou um serviço que caiu e não processou o evento, claro que ele voltando ele pode processar mas nesse tempo se alguma outra transação aconteceu e ele tá 1 passo atrás não daria problema também ?
Eu trabalho em um projeto que usa eventos em um event bus e realmente foi meio confuso no início pra mim. Quando eventos podem ser lançados de mais de um lugar fica muito ruim debugar. Meu time está migrando para um esquema de notificações mas por interfaces. O repositório pode ser um notifier e todos os interessados se registram nele. Uma vez que o repositório está na camada de dados (não temos a camada de casos de uso) todas as entidades têm acesso a ele.
Otavio sua explicação é muito boa, mas gostaria de adicionar que seu vídeo ficaria melhor se traduzisse alguns termos, colocasse o termo na tela com tradução e fizesse um resumo no final do vídeo. Por exemplo, se eu quiser ter as 4 facetas vou ter que assistir novamente todo o vídeo. Faz muita falta texto na tela e o resumo no final pra consolidar as idéias.
Gostei bastante! Maravilha!!
Valeu, Yuri!
Olá Otávio! Eu gosto muito de microservico principalmente dirigido a eventos porém tenho dificuldade em documentar esse serviço como faço por exemplo com rest api através do swagger. Se pode fazer um vídeo falando sobre documentação de microservico dirigido a eventos.
Um ponto muito importante quando se trabalha com event driven é a “Idempotência”, principalmente em domínios que envolvem transação financeira.
Pensar em reprocessar eventos sem ter Idempotência bem implementado é um problema grave.
E também ter um mecanismo de retry é imprescindível.
Então junto com Event Driven é legal pensar em Idempotência junto com Inbox e Outbox.
Interessante eu fico vendo o que pode dar errado é ter que fazer um “rollback” ou um serviço que caiu e não processou o evento, claro que ele voltando ele pode processar mas nesse tempo se alguma outra transação aconteceu e ele tá 1 passo atrás não daria problema também ?
Muito boa a explicação dos conceitos. Descobri o canal ontem já assisti uns 10 vídeos. Conteúdo top :D
Excelente, Davi, muito obrigado!
Eu trabalho em um projeto que usa eventos em um event bus e realmente foi meio confuso no início pra mim. Quando eventos podem ser lançados de mais de um lugar fica muito ruim debugar.
Meu time está migrando para um esquema de notificações mas por interfaces. O repositório pode ser um notifier e todos os interessados se registram nele. Uma vez que o repositório está na camada de dados (não temos a camada de casos de uso) todas as entidades têm acesso a ele.
Otavio sua explicação é muito boa, mas gostaria de adicionar que seu vídeo ficaria melhor se traduzisse alguns termos, colocasse o termo na tela com tradução e fizesse um resumo no final do vídeo. Por exemplo, se eu quiser ter as 4 facetas vou ter que assistir novamente todo o vídeo. Faz muita falta texto na tela e o resumo no final pra consolidar as idéias.
E essa camisa da thumb com as camadas da CA? Vai botar pra rolo? Kkkk