Nota:
El acceso a esta página requiere autorización. Puede intentar iniciar sesión o cambiar directorios.
El acceso a esta página requiere autorización. Puede intentar cambiar los directorios.
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 las dependencias de subsistemas externos no limiten el diseño de una aplicación. Eric Evans describió primero este patrón en Domain-Driven Diseño: Abordar la complejidad en el corazón del software.
Contexto y problema
La mayoría de las aplicaciones dependen de otros sistemas para algunos datos o funcionalidades. Por ejemplo, al migrar una aplicación heredada a un sistema moderno, es posible que la aplicación siga usando los recursos heredados existentes. Las nuevas funcionalidades deben poder llamar al sistema heredado. Esta funcionalidad es especialmente importante para las migraciones graduales en las que se mueven diferentes características de una aplicación más grande a un sistema moderno a lo largo del tiempo.
Estos sistemas heredados suelen tener problemas de calidad, como esquemas de datos convoluados o API obsoletas. Las características y tecnologías que usan los 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.
Cuando se mantiene el acceso entre los sistemas nuevos y heredados, se fuerza 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, esta compatibilidad daña 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.
Solución
Aísle los distintos subsistemas colocando una capa anticorrupción entre ellos. Esta capa traduce la comunicación entre los dos sistemas. Con este enfoque, puede mantener un sistema sin cambios sin poner en peligro el diseño y el enfoque tecnológico del otro.
Descargue un archivo de Visio de esta arquitectura.
El diagrama muestra una aplicación que tiene dos subsistemas. El 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 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. Puede implementar la capa como componente dentro de la aplicación o como un servicio independiente.
Problemas y consideraciones
Tenga en cuenta los siguientes puntos a medida que decida cómo implementar este patrón:
La capa contra daños agrega latencia a las llamadas entre los dos sistemas.
La capa contra daños agrega un servicio adicional que debe administrar y mantener.
Tenga en cuenta cómo planea escalar la capa contra daños.
Tenga en cuenta si necesita más de una capa de anticorrupción. Por ejemplo, puede que desee descomponer la funcionalidad en varios servicios que usan diferentes tecnologías o lenguajes.
Tenga en cuenta cómo planea administrar la capa de protección contra daños en relación con otras aplicaciones o servicios y cómo integrarla en los procesos de supervisión, lanzamiento y configuración.
Asegúrese de mantener y supervisar la coherencia de las transacciones y los datos.
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 es permanente o si planea retirarla después de migrar toda la funcionalidad heredada.
El diagrama anterior usa subsistemas distintos para ilustrar este patrón, pero también puede aplicarlo a otras arquitecturas de servicio, como la integración de código heredada en una arquitectura monolítica.
Dado que la capa contra daños media sistemas que pueden tener distintos niveles de confianza, considere la posibilidad de aplicar la validación y la sanación de entrada en este límite.
Planee la observabilidad, incluidos los identificadores de correlación y el registro estructurado, para diagnosticar errores de traducción.
Cuándo usar este patrón
Use este patrón en los siguientes supuestos:
Tiene previsto que se produzca una migración en varias fases, pero debe 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 podría no ser adecuado cuando:
- Los sistemas nuevos y heredados no tienen diferencias semánticas significativas. En este escenario, es importante centrar la capa contra daños en la lógica de traducción. Evite colocar reglas de negocios o orquestación en la capa.
Diseño de cargas de trabajo
Evalúe cómo usar el patrón Capa contra daños en el diseño de una carga de trabajo para abordar los objetivos y principios descritos en los pilares de Azure Well-Architected Framework. En la tabla siguiente se proporciona una guía sobre cómo este patrón apoya los objetivos de cada pilar.
| 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 nuevo diseño de componentes se mantenga no influido por implementaciones heredadas que podrían tener diferentes modelos de datos o reglas de negocio cuando se integran con estos sistemas heredados. Puede reducir la deuda técnica en nuevos componentes, a la vez que admite componentes existentes. - OE:04 Herramientas y procesos - OE:07 Sistema de supervisión |
Si este patrón introduce concesiones dentro de un pilar, considérelas en relación con los objetivos de los otros pilares.
Example
Este patrón es conceptual y se origina en el enfoque de desarrollo de software de diseño controlado por dominio. Azure servicios como Azure API Management o Azure Functions pueden ayudar con el control y la traducción de protocolos, pero el propósito principal de una capa contra daños es proteger el modelo de dominio, no para recetar ninguna opción de producto específica.
En el ejemplo siguiente, API Management controla la exposición externa y los problemas de protocolo. Azure Functions implementa la capa contra daños a través de la asignación de dominios entre el nuevo sistema y el sistema heredado. Azure Monitor y Application Insights proporcionan la observabilidad que necesita para realizar un seguimiento del éxito y la latencia de la traducción entre los dos subsistemas.
Además de este modelo de solicitud-respuesta sincrónica, la capa de daños también puede usar un enfoque asincrónico controlado por eventos. Mediante el uso de Azure Service Bus, Azure Event Grid o Azure Event Hubs, la capa desacopla el dominio moderno de las restricciones de rendimiento del sistema heredado para permitir la traducción basada en mensajes para cargas de trabajo de alto rendimiento o muy desacopladas.
Pasos siguientes
Explore los patrones de diseño en la nube que ayudan a administrar transacciones distribuidas y a mantener la coherencia de los datos, como el patrón de transacción de compensación y el patrón de transacciones distribuidas de Saga.
Dado que la capa contra daños puede convertirse en un único punto de error, planee la resistencia mediante el patrón reintentos, el patrón Circuit Breaker, el patrón Bulkhead y el patrón de supervisión de puntos de conexión de mantenimiento.