Microservicios y modelo canónico

Cuando estaba leyendo sobre microservicios en este sitio , me encontré con la siguiente declaración. ¿Qué se entiende por esquema canónico? ¿No es lo mismo que el modelo de dominio?

El patrón de Arquitectura de microservicios también rechaza otras partes de SOA, como el concepto de un esquema canónico.

— Punter Vicky
fuente

¿Sabrías cuál es la fuente de esa declaración? (para fines de vinculación)

— Jack

Claro Jack, está aquí - nginx.com/blog/introduction-to-microservices/…

— Punter Vicky

Supongo que este artículo de Wikipedia es lo que estás buscando. Sin embargo, no encuentro el artículo fácil de entender.

— Arseni Mourzenko

Gracias @ArseniMourzenko. Creo que incluso en la arquitectura de microservicios, la solicitud y la respuesta tienen que cumplir con algún modelo de datos. Aún no es incapaz de entender por qué la arquitectura de microservicios lo rechaza.

— Punter Vicky

Algunos modelos de datos sí, pero me parece que el artículo se refiere a modelos de datos "compartidos" o "comunes" entre 2 o más servicios. El esquema canónico es un patrón destinado a salvar servicios de transformaciones de datos en tiempo de ejecución. Un "lenguaje" común entre los servicios. Parece que el artículo hace hincapié en la independencia total de la EM del "ecosistema" en el que vive. Tomemos por ejemplo la mención que le hace a ESB. ESB generalmente exige un modelo de datos empresariales (mensajes) que será común para todos en el bus. MS rechaza estar conectado a cualquier restricción del sistema externo.

— Laiv

Respuestas:

Disculpas de antemano por confiar en el comentario de @ArseniMourzenko, pero una vez que comencé a leer la Wikipedia, entendí de inmediato lo que significa el esquema canónico .

Aquí el comentario de OP que se centra en la duda real

Creo que incluso en la arquitectura de microservicios, la solicitud y la respuesta tienen que cumplir con algún modelo de datos.

Algunos modelos de datos sí, pero parece que el artículo se refiere a modelos de datos "compartidos" o "comunes" entre 2 o más servicios.

El esquema canónico es un patrón destinado a salvar servicios de transformaciones de datos en tiempo de ejecución. También le ahorra duplicar código. Pero también está acoplando su servicio a un modelo de datos externo también. (Ver diagramas en la página de Wikipedia vinculada anteriormente)

Es una especie de "lenguaje" común entre los servicios.

Parece que el artículo hace hincapié en la independencia total de la EM del "ecosistema" en el que vive.

Tomemos como ejemplo la mención que le hace a ESB.

También evitan mucho el uso de ESB e implementan una funcionalidad similar a ESB en los microservicios.

ESB generalmente exige un modelo de datos empresariales (mensajes) que será común para todos los que están conectados al bus.

Entonces, volviendo al artículo, parece que el autor señala el hecho de que MS rechaza estar conectado a cualquier sistema externo (y sus limitaciones) .

— Laiv
fuente

Gracias @Laiv. Otorgaré la recompensa en 9 horas, así que me está restringiendo :)

— Punter Vicky

Los microservicios tienen que ver con la cohesión apretada y el acoplamiento flojo. Dentro de un microservicio, tiene una estrecha cohesión, pero entre microservicios, tiene un acoplamiento flexible y, por lo tanto, desea evitar esquemas compartidos o contratos de datos. Si descubre que tiene microservicios que realizan llamadas sincrónicas entre sí de una manera que exige que compartan un esquema común, eso puede ser una indicación de que ha definido incorrectamente los límites de su servicio.

Los microservicios deben estar estrechamente alineados con los contextos delimitados, en el lenguaje de diseño dirigido por dominio.

— pnschofield
fuente

If you find that you have microservices making synchronous calls. No necesariamente llamamientos asincrónicos. Podría suceder también con mensajes asíncronos ESB. Creo que se centra en el hecho de estar asociado a esquemas compartidos o contratos de datos. Supongo que en la arquitectura de MS, se debe evitar cualquier comunicación p2p entre servicios. La comunicación debe pasar a través de aplicaciones en lugar de cualquier capa interna (capa de servicio interna) o externa (ESB, cola, etc.)

— Laiv