Implementar una capa de fachada o adaptador entre los diferentes subsistemas que no comparten la misma semántica. Esta capa traduce las solicitudes que un subsistema hace al otro subsistema. Use este patrón para asegurarse de que el diseño de la aplicación no se vea limitado por dependencias de subsistemas externos. Eric Evans describió por primera vez este patrón en Domain-Driven Design (Diseño basado en dominios).
Contexto y problema
La mayoría de las aplicaciones dependen de otros sistemas para obtener determinados datos o funcionalidades. Por ejemplo, cuando se migra una aplicación heredada a un sistema moderno, es posible que siga necesitando recursos heredados existentes. Las nuevas características deben poder llamar al sistema heredado. Esto ocurre especialmente con las migraciones graduales, donde diversas características de una aplicación mayor se trasladan a un sistema moderno con el tiempo.
A menudo estos sistemas heredados experimentan problemas de calidad, como esquemas de datos convolucionados o API obsoletas. Las características y tecnologías que se usan en sistemas heredados pueden variar ampliamente respecto a las empleadas en sistemas más modernos. Para interoperar con el sistema heredado, puede que la nueva aplicación necesite admitir elementos no actualizados, como una infraestructura, protocolos, modelos de datos, API u otras características, que de lo contrario no incluiría en una aplicación moderna.
Mantener el acceso entre sistemas nuevos y heredados puede forzar al nuevo sistema a ajustarse a al menos algunas de las API o a una semántica distinta del sistema heredado. Cuando estas características heredadas tienen problemas de calidad, al admitirlas se "corrompe" lo que, en caso contrario, podría ser una aplicación moderna con un diseño inmaculado.
Pueden surgir problemas similares con cualquier sistema externo que su equipo de desarrollo no controle, no solo con sistemas heredados.
Solución
Para aislar los diferentes subsistemas, coloque una capa anticorrupción entre ellos. Esta capa traduce las comunicaciones entre los dos sistemas, lo que permite a un sistema permanecer inalterado mientras que el otro evita poner el riesgo su diseño y su enfoque tecnológico.
El diagrama anterior muestra una aplicación con dos subsistemas. El subsistema A llama al subsistema B a través de una capa anticorrupción. La comunicación entre el subsistema A y la capa anticorrupción siempre usa el modelo de datos y la arquitectura del subsistema A. Las llamadas desde la capa anticorrupción al subsistema B se ajusta al modelo de datos o los métodos de ese subsistema. La capa para evitar daños contiene toda la lógica necesaria para traducir entre los dos sistemas. La capa puede implementarse como un componente dentro de la aplicación o como un servicio independiente.
Problemas y consideraciones
- La capa para evitar daños puede añadir latencia a las llamadas entre los dos sistemas.
- La capa para evitar daños añade un servicio adicional que debe administrarse y mantenerse.
- Tenga en cuenta cómo se escalará la capa para evitar daños.
- Sopese si va a necesitar más de una capa para evitar daños. Es posible que desee descomponer la funcionalidad en varios servicios con diferentes tecnologías o lenguajes o que, por otros motivos, desee crear particiones de la capa para evitar daños.
- Tenga en cuenta cómo se administrará la capa para evitar daños en relación con sus otras aplicaciones o servicios. ¿Cómo se integrará en sus procesos de supervisión, lanzamiento y configuración?
- Asegúrese de mantener la coherencia de la transacción y los datos y de que se pueda supervisar.
- Tenga en cuenta si será necesario que la capa anticorrupción administre todas las comunicaciones entre los diferentes subsistemas o solo un subconjunto de características.
- Si la capa anticorrupción es parte de una estrategia de migración de aplicaciones, considere si será permanente o se retirará después de migrar toda la funcionalidad heredada.
- Este patrón se muestra más arriba con subsistemas distintos, 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 haya planificado una migración en varias fases, pero deba mantenerse la integración entre el sistema nuevo y el heredado.
- Dos o más subsistemas usan una semántica diferente, pero necesitan comunicarse.
Este patrón puede no ser adecuado si no hay ninguna diferencia semántica importante entre el sistema nuevo y el heredado.
Diseño de cargas de trabajo
El arquitecto debe evaluar cómo se puede usar el patrón de capa anti corrupción en el diseño de su carga de trabajo para abordar los objetivos y principios tratados en los pilares del Marco de la Well-Architected de Azure. Por ejemplo:
| Fundamento | Cómo apoya este patrón los objetivos de los pilares |
|---|---|
| La excelencia operativa ayuda a ofrecer calidad de carga de trabajo a través de procesos estandarizados y cohesión de equipos. | Este patrón ayuda a garantizar que el diseño de nuevos componentes no se vea influido por implementaciones heredadas que puedan tener diferentes modelos de datos o reglas de negocio al integrarse con estos sistemas heredados, y puede reducir la deuda técnica de los nuevos componentes sin dejar de dar soporte a los componentes existentes. - OE:04 Herramientas y procesos |
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.