Microsserviços e modelo canônico

Quando eu estava lendo sobre microsserviços neste site , me deparei com a declaração abaixo. O que se entende por um esquema canônico? Não é o mesmo que modelo de domínio?

O padrão de arquitetura de microsserviços também rejeita outras partes da SOA, como o conceito de um esquema canônico.

— Punter Vicky
fonte

Você conheceria a fonte dessa afirmação? (para fins de vinculação)

— Jack

Claro Jack, é aqui - nginx.com/blog/introduction-to-microservices/...

— Punter Vicky

Suponho que este artigo da Wikipedia seja o que você está procurando. No entanto, não acho fácil entender o artigo.

— Arseni Mourzenko

Obrigado @ArseniMourzenko. Acredito que mesmo na arquitetura de microsserviços, a solicitação e a resposta precisam estar em conformidade com algum modelo de dados. Ainda não é possível entender por que é referido como sendo rejeitado pela arquitetura de microsserviço.

— precisa

Alguns modelos de dados sim, mas me parece, que o artigo está se referindo a modelos de dados "compartilhados" ou "comuns" entre 2 ou mais serviços. O esquema canônico é um padrão destinado a salvar serviços de transformações de dados em tempo de execução. Uma "linguagem" comum entre serviços. Parece que o artigo está enfatizando a total independência do MS do "ecossistema" em que vive. Tomemos, por exemplo, a menção que faz ao ESB. O ESB geralmente exige um modelo de dados corporativos (mensagens) que será comum a todos no barramento. A Microsoft rejeita ser anexada a qualquer constrição de sistema externo.

— LAIV

Respostas:

Desculpas antecipadas por confiar no comentário @ArseniMourzenko, mas uma vez que comecei a ler a Wikipedia, entendi imediatamente o que significa Esquema Canônico .

Aqui o comentário do OP que foca a dúvida real

Acredito que mesmo na arquitetura de microsserviços, a solicitação e a resposta precisam estar em conformidade com algum modelo de dados.

Alguns modelos de dados são sim, mas parece que o artigo está se referindo a modelos de dados "compartilhados" ou "comuns" entre 2 ou mais serviços.

O esquema canônico é um padrão destinado a salvar serviços de transformações de dados em tempo de execução. Também evita que você duplique o código. Mas você também acoplará seu serviço a um modelo de dados externo. (Veja diagramas na página da Wikipedia vinculada acima)

É uma espécie de "linguagem" comum entre serviços.

Parece que o artigo está enfatizando a total independência do MS do "ecossistema" em que vive.

Tomemos, por exemplo, a menção que faz ao ESB.

Eles também evitam o uso de ESBs e implementam funcionalidades semelhantes a ESB nos próprios microsserviços.

O ESB geralmente exige um modelo de dados corporativos (mensagens) que será comum a todos os que estão conectados ao barramento.

Então, voltando ao artigo, parece que o autor está apontando para o fato de que a MS rejeita ser anexada a qualquer sistema externo (e suas restrições) .

— Laiv
fonte

Obrigado @Laiv. Eu premiará a recompensa em 9 horas - por isso está me restringindo :)

— Punter Vicky

Os microsserviços têm tudo a ver com coesão firme e acoplamento flexível. Em um microsserviço, você tem uma coesão rígida, mas entre microsserviços, você tem um acoplamento fraco e, portanto, deseja evitar esquemas compartilhados ou contratos de dados. Se você achar que os microsserviços fazem chamadas síncronas entre si de uma maneira que exija que eles compartilhem um esquema comum, isso pode ser uma indicação de que você definiu seus limites de serviço incorretamente.

Os microsserviços devem estar estreitamente alinhados com os Contextos limitados, na linguagem Design orientada a domínio.

— pnschofield
fonte

If you find that you have microservices making synchronous calls. Chamadas não necessariamente assíncronas. Isso também pode acontecer com mensagens assíncronas do ESB. Eu acho que o foco é o fato de ser associado a esquemas compartilhados ou contratos de dados. Suponho que na arquitetura do MS, deve-se evitar qualquer comunicação P2P entre serviços. A comunicação deve ocorreu através de aplicações em vez de qualquer (camada interior) serviço interno ou externo (ESB, fila, etc) camada

— LAIV