La gran mayoría de las empresas con sistemas informáticos no son capaces, por muchas condiciones justificadas o no, de seguir la evolución continua del mundo tecnológico en estos años. Muchas de estas no prevén la adaptación de sus sistemas a pequeñas pero continuas evoluciones de frameworks, lenguajes de programación, actualizaciones de seguridad, etc.
Estas afirmaciones llevan a un escenario donde se encuentran con la necesidad imperiosa de actualizar sus productos informáticos y se ven limitadas por la dificultad de poder migrar dichos productos o implementaciones legacy a las nuevas tecnologías.
Un aliado para afrontar estas condiciones en nuestros desarrollos es el patrón anti-corruption layer.
Un escenario real
Afrontar un cambio en el código parte del análisis e implementación de los patrones de arquitectura y diseño que mejor se adapten. Los patrones de arquitectura, traen implícitamente una serie de convenciones que debemos asumir para que nuestro código sea limpio y mantenible. Estas mismas convenciones o buenas prácticas muchas veces chocan con nuestro código legacy.
También se dificulta extraer la lógica de negocio, desacoplar módulos o interfaces, librerías de acceso a datos, etc.
La anti-corruption layer nos ayuda a preservar nuestra nueva arquitectura sin incluir viejos vicios y malas prácticas en nuestro nuevo código.
Que patrones intervienen en nuestro enfoque
Hay tres patrones que nos garantizan este proceso de refactorización: el patrón Adapter, el patrón Facade y el patrón Translator
El patrón Adapter, garantiza que dos elementos que, en principio, no pueden interactuar por incompatibilidades, logren comunicarse entre ellos. Este patrón transforma una interfaz en otra para que sea consumido por un cliente.
El patrón Facade, se utiliza cuando se tiene un sistema que interactúa con otro dividido en múltiples subsistemas. Una petición a una Facade, desde un sistema, puede desembocar en múltiples peticiones en el otro sistema.
El patrón Translator ayuda a que entidades de los módulos legacy puedan ser interpretadas dentro de la nueva arquitectura. Resumiendo, sería como un mapper entre modelos de diferentes contextos.
En resumen, nuestra anti-corruption layer evita que en nuestra nueva arquitectura hagamos referencias directas o acoples con la vieja arquitectura.
Un ejemplo de aplicación de este flujo.
Si tenemos un formulario web sin un controlador claramente definido en tu código heredado, que gestiona los datos, pudiésemos llamar a la anti-corruption layer. A través del adaptador (Adapter) tu clase legacy puede transformarse en una clase más sencilla usando la fachada (Facade), para que finalmente termine llamando al controlador de la nueva arquitectura. Los tipos y datos pueden ser transformador a través del traductor (Translator) usando lógicas de mapeos.
De la misma manera, la nueva arquitectura es posible que necesite alguna lógica, estructura de datos, etc. de la antigua aplicación y para evitar las referencias no deseadas usamos la anti-corruption layer manteniendo nuestro código limpio y aplicando convenciones y patrones de la nueva arquitectura.
Un “aliado/enemigo” en el proceso de migración
Para refactorizar nuestra aplicación durante el proceso de migración a una nueva arquitectura es esencial que dispongamos de mecanismos intermedios como la anti-corruption layer. Hay cambios progresivos que pueden consumir directamente el nuevo desarrollo, pero hay otros que por su complejidad no permiten hacerlo de manera inmediata.
También hay que considerar que los desarrollos modernos necesiten el uso de recursos, infraestructuras heredadas que requieran refactorizaciones futuras en nuestra aplicación moderna, incluso aplicando la anti-corruption layer.
Es importante considerar que este patrón puede incluir demoras en la comunicación entre módulos por la lógica que infiere. Además, de tener en cuenta el mantenimiento y desarrollo de la misma capa, hay que considerar su temporalidad en todo el sistema o incluso que sea permanente en algunos escenarios.
Independientemente de algunas desventajas, en migraciones muy complejas o sistemas heredados muy antiguos, es una herramienta contrastada que garantiza la modernización de nuestras aplicaciones.
