Nota
O acceso a esta páxina require autorización. Pode tentar iniciar sesión ou modificar os directorios.
O acceso a esta páxina require autorización. Pode tentar modificar os directorios.
Azure
Azure Logic Apps
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 funcionalidades 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 tienen 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 tenga que 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, su soporte "corrompe" lo que de otro modo podría ser una aplicación moderna diseñada de manera limpia.
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 anticorrupción 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 anti-corrupción. La comunicación entre el subsistema A y la capa de anticorrupción siempre usa el modelo de datos y la arquitectura del subsistema A. Las llamadas desde la capa de anticorrupción al subsistema B se ajustan al modelo de datos o métodos de ese 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 podría agregar latencia a las llamadas realizadas entre los dos sistemas.
- La capa anticorrupción agrega un servicio adicional que se debe administrar y mantener.
- Tenga en cuenta cómo crecerá su capa anticorrupción.
- Tenga en cuenta si necesita más de una capa de anticorrupción. Es posible que desee descomponer la funcionalidad en varios servicios mediante diferentes tecnologías o lenguajes de programación, o puede que existan otras razones para dividir la capa anti-corrupción.
- Tenga en cuenta cómo se administrará la capa anticorrupción en relación con sus 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.
Es posible que este patrón no sea 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 de Capa Anti-corrupción 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 |
|---|---|
| La excelencia operativa ayuda a ofrecer calidad de carga de trabajo a través de procesos estandarizados y cohesión de equipos. | El patrón ayuda a garantizar que el nuevo diseño de componentes permanezca no influido por implementaciones heredadas que podrían tener diferentes modelos de datos o reglas de negocio cuando se integra con dichos sistemas heredados, y puede reducir la deuda técnica en nuevos componentes, a la vez que sigue apoyando 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.