2
respostas

[Dúvida] Criando um consumer na prática

No curso, fizemos o consumer junto com a API do ItemRestaurante, e me surgiram algumas dúvidas pois ambos estão no mesmo projeto/executável:

  1. Essa prática é realmente utilizada na vida real, ou foi utilizada dessa forma pra deixar o curso mais simples? Digo isso pois pensando por cima, se eu quisesse escalar somente o meu consumer, eu obrigatoriamente estaria escalando junto a minha API. Nesse caso estou escalando algo que eu não queria mas sou obrigado pois é a mesma aplicação.

  2. Um microserviço na prática, ele é caracterizado apenas como uma API? (falando bem superficialmente)

  3. Como funciona a lógica do consumer exatamente, ele teria regras de negócios dentro dele? Iria acessar diretamente o domínio da aplicação falando em DDD, inserir no banco, etc, ou ele apenas iria fazer requisições pra uma API que é lá onde estaria toda a lógica?

2 respostas

Olá, Lucas! Tudo beleza camarada?

Ótimo ver que você está estudando sobre a implementação de comunicação em microsserviços usando .NET6. Vamos às suas dúvidas:

  1. A prática de ter o consumer junto com a API do ItemRestaurante no mesmo projeto/executável é comum em cenários mais simples, como em um ambiente de desenvolvimento ou em pequenos projetos. No entanto, em cenários de produção, é comum separar o consumer e a API em projetos diferentes, para permitir escalabilidade independente. Dessa forma, você pode escalar somente o consumer sem precisar escalar a API. Portanto, a prática utilizada no curso foi simplificada para facilitar o aprendizado, mas é importante entender que, na vida real, é possível separar essas responsabilidades.

  2. Um microserviço, de forma superficial, é caracterizado como uma unidade de software independente que pode ser implantada e escalada separadamente. Embora uma API seja uma forma comum de implementar um microserviço, não é a única opção. Um microserviço pode ser implementado usando diferentes tecnologias e protocolos de comunicação, como gRPC ou mensagens assíncronas. O importante é que ele seja independente e possa ser implantado e escalado separadamente dos outros componentes do sistema.

  3. A lógica do consumer pode variar dependendo do contexto e dos requisitos do sistema. Em geral, o consumer é responsável por consumir as mensagens enviadas pelo produtor e realizar as ações necessárias com base nessas mensagens. Isso pode incluir a inserção de dados no banco de dados, a execução de regras de negócio específicas ou a chamada de outras APIs para realizar operações adicionais. Em relação ao DDD, o consumer pode ter acesso ao domínio da aplicação, mas é importante ter cuidado para não violar os princípios de separação de responsabilidades.

Espero ter ajudado a esclarecer suas dúvidas! Se tiver mais alguma pergunta, é só me dizer. Bons estudos!

Olá André! Obrigado pela resposta.

Sobre os dois primeiros pontos não tenho mais dúvidas. Sobre o ponto 3, entendi que podem existir casos diferentes, porém se por exemplo, eu tenho minha própria API, faria sentido meu consumer utiliza-la? Pensando por alto parece que fica muito atrelado e ocorre muita dependência. No meu caso eu utilizo clean architecture, do jeito que eu penso, sem usar api, o consumer iria apenas ter dependencia com a camada Domain e persistência, nesse caso não haveria problemas?

Quer mergulhar em tecnologia e aprendizagem?

Receba a newsletter que o nosso CEO escreve pessoalmente, com insights do mercado de trabalho, ciência e desenvolvimento de software