Patrón de ramificación según abstracción

El patrón de higo estrangulador funciona bien cuando se pueden interceptar las llamadas en el perímetro del monolito. Sin embargo, si desea modernizar los componentes que se encuentran en una parte más profunda de la pila de aplicaciones antiguas y que tienen dependencias previas, le recomendamos que utilice un patrón de ramificación por abstracción. Este patrón le permite realizar cambios en la base de código existente para permitir que la versión modernizada coexista de forma segura con la versión antigua sin causar interrupciones.

Para utilizar correctamente el patrón de ramificación por abstracción, siga este proceso:

1. Identifique los componentes monolíticos que tienen dependencias ascendentes.

2. Cree una capa de abstracción que represente las interacciones entre el código que se va a modernizar y sus clientes.

3. Cuando la abstracción esté lista, cambie los clientes existentes para que usen la nueva abstracción.

4. Cree una nueva implementación de la abstracción con la funcionalidad rediseñada fuera del monolito.

5. Cambie la abstracción a la nueva implementación cuando esté lista.

6. Cuando la nueva implementación proporcione a los usuarios todas las funciones necesarias y el monolito ya no esté en uso, limpie la implementación anterior.

El patrón de ramificación por abstracción suele confundirse con la alternancia de características, que también permite realizar cambios en el sistema de forma incremental. La diferencia es que los cambios de característica están diseñados para permitir el desarrollo de nuevas características y mantenerlas invisibles para los usuarios cuando el sistema está en ejecución. Por lo tanto, los conmutadores de características se utilizan en el momento de la implementación o en el tiempo de ejecución para elegir si una característica o conjunto de características en particular es visible en la aplicación. La ramificación mediante abstracción es una técnica de desarrollo y se puede combinar con la alternancia de características para cambiar entre la implementación anterior y la nueva.

En la siguiente tabla se explican las ventajas y desventajas de usar el patrón de ramificación según abstracción.

Ventajas

Desventajas

Permite realizar cambios incrementales que son reversibles en caso de que algo vaya mal (compatible con versiones anteriores). Te permite extraer la funcionalidad que se encuentra en lo más profundo del monolito cuando no puedes interceptar las llamadas que se reciben en la periferia del monolito. Permite que varias implementaciones coexistan en el sistema de software. Proporciona una forma sencilla de implementar un mecanismo alternativo mediante un paso de verificación intermedio para llamar tanto a las funciones nuevas como a las antiguas. Soporta la entrega continua, ya que el código funciona en todo momento durante la fase de reestructuración.

No es adecuado si se trata de la coherencia de datos. Requiere cambios en el sistema existente. Podría añadir más gastos al proceso de desarrollo, especialmente si la base de código está mal estructurada. (En muchos casos, las ventajas valen el esfuerzo adicional y, cuanto mayor sea la reestructuración, más importante será considerar la posibilidad de utilizar el patrón de ramificación por abstracción).

La siguiente ilustración muestra el patrón de ramificación por abstracción de un componente notificación del monolito de los seguros. Comienza con la creación de un resumen o interfaz para la funcionalidad de notificación. En pequeños incrementos, los clientes existentes se cambian para usar la nueva abstracción. Esto puede requerir buscar en la base de código las llamadas a las API relacionadas con el componente notificación. Cree la nueva implementación de la funcionalidad de notificación como un microservicio fuera de su monolito y la aloje en la arquitectura modernizada. Dentro del monolito, la interfaz de abstracción recién creada actúa como intermediaria y muestra la nueva implementación. En pequeños incrementos, se transfiere la funcionalidad de notificación a la nueva implementación, que permanece inactiva hasta que esté completamente probada y lista. Cuando la nueva implementación esté lista, se cambia la abstracción para utilizarla. Es recomendable utilizar un mecanismo de conmutación que se pueda cambiar fácilmente (por ejemplo, un conmutador de característica) para poder volver a la antigua funcionalidad con facilidad en caso de que surja algún problema. Cuando la nueva implementación comience a ofrecer todas las funciones de notificación a los usuarios y el monolito ya no esté en uso, podrá limpiar la implementación anterior y eliminar cualquier indicador de característica de conmutación que haya implementado