Patrón de capa anticorrupción
Implemente una capa de fachada o adaptador entre distintos subsistemas que no compartan la misma semántica. Esta capa traduce las solicitudes que realiza un subsistema al otro subsistema. Use este patrón para asegurarse de que el diseño de una aplicación no está limitado por las dependencias de subsistemas externos. Este patrón fue descrito por primera vez por Eric Evans en Domain-Driven Design.
Contexto y problema
La mayoría de las aplicaciones dependen de otros sistemas para algunos datos o funcionalidades. Por ejemplo, cuando se migra una aplicación heredada a un sistema moderno, es posible que todavía necesite recursos heredados existentes. Las nuevas características deben poder llamar al sistema heredado. Esto es especialmente cierto en las migraciones graduales, donde las diferentes características de una aplicación mayor se mueven a un sistema moderno a lo largo del tiempo.
A menudo, estos sistemas heredados sufren problemas de calidad, como esquemas de datos involuados o API obsoletas. Las características y tecnologías usadas en sistemas heredados pueden variar ampliamente de sistemas más modernos. Para interoperar con el sistema heredado, es posible que la nueva aplicación necesite admitir infraestructuras, protocolos, modelos de datos, API u otras características obsoletas que no se colocarían en una aplicación moderna.
Mantener el acceso entre los sistemas nuevos y heredados puede obligar al nuevo sistema a cumplir al menos algunas de las API del sistema heredadas u otra semántica. Cuando estas características heredadas tienen problemas de calidad, admitirlos "dañados" lo que podría ser una aplicación moderna diseñada limpiamente.
Pueden surgir problemas similares con cualquier sistema externo que el equipo de desarrollo no controle, no solo los sistemas heredados.
Solución
Aísle los distintos subsistemas colocando una capa de daños entre ellos. Esta capa traduce las comunicaciones entre los dos sistemas, lo que permite que un sistema permanezca sin cambios, mientras que el otro puede evitar poner en peligro su diseño y enfoque tecnológico.
En el diagrama anterior se muestra una aplicación con dos subsistemas. Subsistema A llama al subsistema B a través de una capa contra daños. La comunicación entre el subsistema A y la capa contra daños siempre usa el modelo de datos y la arquitectura del subsistema A. Llama desde la capa anti-corrupta al subsistema B conforme al modelo de datos o métodos del subsistema. La capa contra daños contiene toda la lógica necesaria para traducir entre los dos sistemas. La capa se puede implementar como un componente dentro de la aplicación o como un servicio independiente.
Problemas y consideraciones
- La capa contra daños puede agregar latencia a las llamadas realizadas entre los dos sistemas.
- La capa contra daños agrega un servicio adicional que se debe administrar y mantener.
- Tenga en cuenta cómo se escalará la capa contra daños.
- Tenga en cuenta si necesita más de una capa contra daños. Es posible que desee descomponer la funcionalidad en varios servicios mediante diferentes tecnologías o lenguajes, o puede haber otras razones para dividir la capa contra daños.
- Tenga en cuenta cómo se administrará la capa contra daños en relación con otras aplicaciones o servicios. ¿Cómo se integrará en los procesos de supervisión, lanzamiento y configuración?
- Asegúrese de que se mantienen las transacciones y la coherencia de los datos y se pueden supervisar.
- Tenga en cuenta si la capa contra daños debe controlar toda la comunicación entre distintos subsistemas o simplemente un subconjunto de características.
- Si la capa de protección contra daños forma parte de una estrategia de migración de aplicaciones, considere si será permanente o se retirará después de migrar todas las funcionalidades heredadas.
- Este patrón se ilustra con subsistemas distintos anteriores, pero también se puede aplicar a otras arquitecturas de servicio, como al integrar código heredado en una arquitectura monolítica.
Cuándo usar este patrón
Use este patrón en los siguientes supuestos:
- Se planea realizar una migración en varias fases, pero es necesario mantener la integración entre los sistemas nuevos y heredados.
- Dos o más subsistemas tienen una semántica diferente, pero deben comunicarse.
Este patrón puede no ser adecuado si no hay diferencias semánticas significativas entre los sistemas nuevos y heredados.
Diseño de cargas de trabajo
Un arquitecto debe evaluar cómo se puede usar el patrón Capa contra daños en el diseño de su carga de trabajo para abordar los objetivos y principios descritos en los pilares de Azure Well-Architected Framework. Por ejemplo:
| Fundamento | Cómo apoya este patrón los objetivos de los pilares |
|---|---|
| Este patrón ayuda a garantizar que el nuevo diseño de componentes permanece influido por implementaciones heredadas que podrían tener diferentes modelos de datos o reglas de negocio cuando se integra con estos sistemas heredados y puede reducir la deuda técnica en nuevos componentes, a la vez que admite componentes existentes. - Herramientas y procesos de OE:04 |
Al igual que con cualquier decisión de diseño, hay que tener en cuenta las ventajas y desventajas con respecto a los objetivos de los otros pilares que podrían introducirse con este patrón.