Entendi o conceito dos contextos e a razão de isolá-los na aplicação, porém o professor criou um pacote chamado shared. Ao modificar a arquitetura da aplicação para micro serviços, como seria tratada essa camada shared?
Solucionado
Entendi o conceito dos contextos e a razão de isolá-los na aplicação, porém o professor criou um pacote chamado shared. Ao modificar a arquitetura da aplicação para micro serviços, como seria tratada essa camada shared?
hoje, com a Alura e o Google Gemini
Oi Luiz,
No caso de separação em microsserviços é provável que não tenha essa questão de shared context, pois cada microsserviço vai atuar como um Contexto Delimitado, tendo sua representação local dos conceitos do domínio.
Por exemplo, suponha uma aplicação de um e-commerce, na qual um conceito importante é o de Cliente. Podemos ter uma classe para representá-lo da seguinte maneira:
public class Cliente {
private String nome;
private CPF cpf;
private Email email;
}Essa classe provavelmente estaria no shared context, pois seria utilizada em vários contextos distintos da aplicação.
Mas no caso de uma arquitetura baseada em microsserviços é provável que cada microsserviço tenha uma classe Cliente que será distinta uma das outras, pois tem apenas as informações que dizem respeito ao seu contexto.
Em um possível microsserviço de pagamento é provável que precisaremos de mais informações do cliente, como seu endereço, mas para outros microsserviços o endereço pode ser irrelevante.
Perceba então que seria difícil ter uma única representação da classe cliente que é comum para todos os microsserviços, pois teríamos uma classe com dezenas de atributos, sendo que cada microsserviço se interessaria apenas por parte deles.
Antigamente era comum, nessas situações de aplicações distribuidas, de ter um projeto separado somente com as classes comuns e compartilhar um jar desse projeto com os outros.
Mas em arquitetura de microsserviços acredito que essa não seja a abordagem mais utilizada.
Bons estudos!