Capa anticorrupción en los microservicios. #microservicio #anticorruptionlayer

La interacción con aplicaciones/servicios externos es común en todas las aplicaciones, cada día se consumen más servicios externos que ofrecen valor al negocio, por ejemplo: pasarelas de pago, tasas de cambio, capas de servicio de productos legados, apis de productos de terceros como wordpress, prestashop u otros . El número de servicios posibles a consultar es diverso y depende de cada negocio en particular. En el caso particular de los microservicios debemos recordar que uno de sus principales características deseables es que cumplan con el Principio de Responsabilidad Única (SRP). Un microservicio (y una aplicación general) no debe estar atado a los cambios que pueda experimentar un tercero, o al menos debe implementarse un mecanismo adecuado que ayude a disminuir el impacto ante una variación del sistema de terceros con el que se comunica. El desacomplamiento es parte en sí del origen de los microservicios. * Aprende más en nuestro blog: https://sacavix.com/ * Apóyanos en Patreon: https://www.patreon.com/sacavix_tech (Con tu apoyo en Patreon accedes a ventajas exclusivas como directos, preguntas y respuestas en el chat, respuestas a tus dudas y acceso a nuestro libro "Patrones para la implementación de una arquitectura basada en microservicios". Otro punto a considerar es el proceso de transición desde una aplicación monolítica hacia microservicios. Es común en las grandes empresas que exista un producto central, con un API gigante (en ocasiones con tecnologías obsoletas que degradan el rendimiento), y se comienza a migrar esta aplicación a pequeños microservicios. En el proceso de migración van entrando a producción los pequeños microservicios pero aún se usan funcionalidades del monolito que se van sustituyendo a medidas que transcurre la migración. En este proceso ¿vale la pena que los nuevos microservicios se comuniquen directamente con la API del sistema monolítico cuando sabemos que desaparecerá ? La respuesta es evidente. Se requiere entonces crear un mecanismo que posibilite actuar como intermediario en la comunicación con la API externa y que las llamadas a la misma no corrompan el diseño del microservicio agregando código específico que dejará de estar operativo en poco tiempo cuando se deje de usar definitivamente el monolito. Para resolver este problema, debemos aplicar el patrón “Capa de anticorrupción”. #patrones #microservicios #anticorrupcion #resiliencia #anticorruption