Olá pessoal, venho aqui conversar sobre um tema bem interessante.
Atualmente estamos vivendo num momento onde se fala muito de microserviços, sabemos que é algo extremamente importante mas deve ser usado com muito cuidado, trabalhei durante 3 anos com sistemas monoliticos de pequena e grande complexidade, sistemas de alguns ramos que requerem regras de negócio muito especifica, fiz algumas implementações com microserviços para disponibilizar alguns dados através de APIs.
Hoje não trabalho mais com esses tipos de sistema, mas gosto de idealizar sistemas financeiros, controle de estoque e alguns outros, fico pensando se faço mais desacoplado o possível ( regras de negócio em uma API, cadastros em outra, relatórios em outras,etc).
Isso pode por um lado ser bom ( baixo acoplamento e fácil manutenção pois estão bem separados ‘minha opinião’), por outro lado código e regras espalhadas por todo lado.
Na prática se fala sobre SOLID e outras coisas, mas sei que na prática as coisas acontecem um pouco diferente.
Qual sua visão sobre o desacoplamento de serviços???
Se você fosse criar uma API simples, como exemplo um sistema onde vai ter 3 tipo de cadastro,(cliente,produto,pedidos), você faria os 3 numa mesma API ou faria 3 projetos separados.
Obs:Galera, sou novo nessa área de microserviços e tenho estudado muito, qualquer opinião,sugestão, visão desde que construtiva será muito bem vinda.
Criar por criar sem real necessidade é somente Hype, um tiro no próprio pé eu diria, eu partiria do mais simples (KISS Principle), no máximo uma quebra por módulos inicialmente já atende legal, porquê dessa forma já é possível pensar em desacoplamento, e se no futuro surgir a necessidade aí sim vai migrando aos poucos para micro serviços.
Agora se for somente para fins didáticos aí pode criar do jeito que achar mais interessante para aplicar as tecnologias que você tem interesse em aprender e se aprofundar.
Imagine como se fosse um monolito quebrado em pequenas partes isoladas!
Uma analogia simples por exemplo, imagine um projeto maven base que dentro dele você tem N outros projetos, cada projeto deste contido dentro do projeto base é considerado como um módulo.
Tipo isso aqui:
meu-sistema-completo // Projeto maven base
|__ modulo-produtos // Projeto maven isolado
|__ modulo-estoque // Projeto maven isolado
|__ modulo-financeiro // Projeto maven isolado
|__ ....
Rapaiz, trabalho num ambiente que a arquitetura é microserviços. Hoje, vejo essa arquitetura funcionar se a infra estiver adequada (devops deve tah pulsando no ambiente), senão vira vários monolitos pequenos. Fazemos a comunicação entre os microserviços usando eventos kafka e há ferramentas que monitoram as mensagens que são trafegadas (casos de erro sem monitoramento é um caos dos infernos mano).
Exatamente, a ideia é justamente essa, pois se precisar quebrar o projeto em micro serviços posteriormente caso venha a surgir a necessidade de fato, este modelo de arquitetura torna o trabalho um pouco mais simples e menos doloroso.
A ideia principal deste modelo é pensar em desacoplamento de forma geral, porém as coisas ainda se encontram em um mesmo projeto, ou seja, você está simplesmente à um método de distância (pensando em usar a interação entre módulos por interface), e não à uma chamada HTTP ou uma mensagem em um Broker.
Depende de como é usado. Se quem faz o pedido é um site/e-commerce usado pelo consumidor final, Cadastro de Cliente e Pedido poderia ficar em um backend separado. Cadastro de Produto ficaria em outro pra ser usado pela gerencia de compras da empresa. Inclusive seriam sistemas independentes, cada um com seu front, como se fossem pequenos monolitos.
