Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Patrones para la descomposición de monolitos
Una vez que decida descomponer un monolito de su cartera de aplicaciones, debe elegir los patrones de descomposición adecuados e introducirlos en su organización.
**nota**
Puede usar varios patrones para descomponer un monolito. Por ejemplo, puede descomponer un monolito por [capacidad empresarial](decompose-business-capability.md) y, a continuación, utilizar el [patrón de subdominios](decompose-subdomain.md) para desglosarlo más.
**Topics**
+ [Descomponer según capacidad empresarial](decompose-business-capability.md)
+ [Descomponer según subdominio](decompose-subdomain.md)
+ [Descomponer según transacciones](decompose-transactions.md)
+ [Patrón de servicio por equipo](service-per-team.md)
+ [Patrón de higo estrangulador](strangler-fig.md)
+ [Patrón de ramificación según abstracción](branch-by-abstraction.md)
# Descomponer según capacidad empresarial
Puede utilizar las capacidades o los procesos empresariales de su organización para descomponer un monolito. Una *capacidad empresarial* es lo que hace una empresa para generar valor (por ejemplo, ventas, servicio al cliente o marketing). Por lo general, una organización tiene múltiples capacidades empresariales y estas varían según el sector o la industria. Utilice este patrón si su equipo tiene suficiente información sobre las unidades de negocio de su organización y cuenta con expertos en la materia (SMEs) para cada unidad de negocio. En la siguiente tabla se explican las ventajas y desventajas de usar este patrón.
****
| Ventajas | Desventajas |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-business-capability.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-business-capability.html) |
En el siguiente diagrama, un monolito de seguros se divide en cuatro microservicios en función de las capacidades empresariales.
![\[Descomposición de los monolitos por capacidades empresariales\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-business-capability.png)
# Descomponer según subdominio
Este patrón utiliza un subdominio de [diseño basado en dominios (DDD)](https://en.wikipedia.org/wiki/Domain-driven_design) para descomponer los monolitos. Este enfoque divide el modelo de dominio de la organización en subdominios separados que se clasifican como *principales* (un diferenciador clave para la empresa), *secundarios* (posiblemente relacionados con la empresa, pero no como diferenciadores) o *genéricos* (no específicos de la empresa). Este patrón es adecuado para los sistemas monolíticos existentes que tienen límites bien definidos entre los módulos relacionados con los subdominios. Esto significa que puede descomponer el monolito volviendo a empaquetar los módulos existentes como microservicios, pero sin reescribir significativamente el código existente. Cada subdominio tiene un modelo, y el alcance de ese modelo se denomina *contexto limitado*. Los microservicios se desarrollan en torno a este contexto limitado. En la siguiente tabla se explican las ventajas y desventajas de usar este patrón.
****
| Ventajas | Desventajas |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-subdomain.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-subdomain.html) |
La siguiente ilustración muestra cómo un monolito de seguros se puede descomponer en subdominios después de que las capacidades empresariales lo hayan descompuesto.
![\[Descomposición de los monolitos por subdominios\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-subdomain.png)
La ilustración muestra que los servicios de *ventas* y *marketing* se dividen en microservicios más pequeños. Los modelos de *compras* y *reclamaciones* son elementos diferenciadores comerciales importantes para *ventas* y se dividen en dos microservicios independientes. El *marketing* se descompone mediante el uso de funcionalidades empresariales de apoyo, como las *campañas*, los *análisis* y los *informes.*
# Descomponer según transacciones
En un sistema distribuido, una aplicación normalmente tiene que llamar a varios microservicios para completar una transacción comercial. Para evitar problemas de latencia o de confirmación en dos fases, puede agrupar los microservicios en función de las transacciones. Este patrón es adecuado si considera que los tiempos de respuesta son importantes y sus distintos módulos no crean un monolito después de empaquetarlos. En la siguiente tabla se explican las ventajas y desventajas de usar este patrón.
****
| Ventajas | Desventajas |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-transactions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-transactions.html) |
En la siguiente ilustración, el monolito de los seguros se divide en varios microservicios en función de las transacciones.
![\[Descomposición de los monolitos por transacciones\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-transaction.png)
En un sistema de seguros, una solicitud de reclamación normalmente se etiqueta a un cliente después de haberla enviado. Esto significa que un servicio de reclamaciones no puede existir sin un microservicio del *Cliente*. Las *ventas* y los *clientes* se agrupan en un solo paquete de microservicios, y una transacción comercial requiere la coordinación con ambos.
# Patrón de servicio por equipo
En lugar de descomponer los monolitos por capacidades o servicios empresariales, el patrón de servicio por equipo los divide en microservicios gestionados por equipos individuales. Cada equipo es responsable de una capacidad empresarial y es propietario del código base de la capacidad. El equipo desarrolla, prueba, despliega o escala sus servicios de forma independiente y, sobre todo, interactúa con otros equipos para negociar. APIs Le recomendamos que asigne cada microservicio a un solo equipo. Sin embargo, si el equipo es lo suficientemente grande, varios subequipos podrían tener microservicios independientes dentro de la misma estructura de equipo. En la siguiente tabla se explican las ventajas y desventajas de usar este patrón.
****
| Ventajas | Desventajas |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/service-per-team.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/service-per-team.html) |
La siguiente ilustración muestra cómo se puede dividir un monolito en microservicios gestionados, mantenidos y suministrados por equipos individuales.
![\[Descomposición de monolitos en microservicios por equipos\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/service-per-team.png)
# Patrón de higo estrangulador
Los patrones de diseño discutidos hasta ahora en esta guía se aplican a las aplicaciones en descomposición para proyectos totalmente nuevos. ¿Qué pasa con los proyectos abandonados que implican aplicaciones grandes y monolíticas? Será difícil aplicarles los patrones de diseño anteriores, ya que dividirlos en trozos más pequeños mientras se utilizan activamente es una tarea ardua.
El [patrón de higo estrangulador](https://martinfowler.com/bliki/StranglerFigApplication.html) es un patrón de diseño popular que fue introducido por Martin Fowler, quien se inspiró en un determinado tipo de higo que se siembra él solo en las ramas superiores de los árboles. El árbol existente se convierte inicialmente en una estructura de soporte para la nueva higuera. Luego, el higo envía sus raíces al suelo, envolviendo gradualmente el árbol original y dejando solo el higo nuevo en su lugar, que se sostiene por sí mismo.
Este patrón se suele utilizar para transformar gradualmente una aplicación monolítica en microservicios mediante la sustitución de una funcionalidad concreta por un servicio nuevo. El objetivo es que las versiones heredadas y las nuevas y modernizadas coexistan. El nuevo sistema inicialmente es compatible con el sistema existente y lo complementa. Este soporte da tiempo al nuevo sistema para crecer y, potencialmente, reemplazar por completo el sistema anterior.
El proceso de transición de una aplicación monolítica a un microservicio mediante la implementación del patrón de higo estrangulador consta de tres pasos: transformar, coexistir y eliminar:
+ *Transformar*: identifique y cree componentes modernizados portándolos o reescribiéndolos en paralelo con la aplicación heredada.
+ *Coexistir*: conserve la aplicación monolítica para su reversión. Intercepte las llamadas externas al sistema incorporando un proxy HTTP (por ejemplo, [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)) en el perímetro de su monolito y redirija el tráfico a la versión modernizada. Esto le ayuda a implementar la funcionalidad de forma incremental.
+ *Eliminar*: retire la funcionalidad anterior del monolito a medida que el tráfico se redirige del monolito heredado al servicio modernizado.
En la siguiente tabla se explican las ventajas y desventajas de usar el patrón de higo estrangulador.
****
| Ventajas | Desventajas |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/strangler-fig.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/strangler-fig.html) |
La siguiente ilustración muestra cómo se puede dividir un monolito en microservicios aplicando el patrón del higo estrangulador a la arquitectura de una aplicación. Ambos sistemas funcionan en paralelo, pero empezará a trasladar la funcionalidad fuera de la base de código monolítica y a mejorarla con nuevas capacidades. Estas nuevas capacidades le brindan la oportunidad de diseñar los microservicios de la manera que mejor se adapte a sus necesidades. Seguirá eliminando las capacidades del monolito hasta que todas sean reemplazadas por microservicios. En ese momento podrá eliminar la aplicación monolítica. El punto clave a tener en cuenta aquí es que tanto el monolito como los microservicios convivirán durante un período de tiempo.
![\[Descomposición de monolitos en microservicios utilizando el patrón de higo estrangulador\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/strangler-fig.png)
# 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.
1. Cree una capa de abstracción que represente las interacciones entre el código que se va a modernizar y sus clientes.
1. Cuando la abstracción esté lista, cambie los clientes existentes para que usen la nueva abstracción.
1. Cree una nueva implementación de la abstracción con la funcionalidad rediseñada fuera del monolito.
1. Cambie la abstracción a la nueva implementación cuando esté lista.
1. 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](http://martinfowler.com/bliki/FeatureToggle.html), 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 |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/branch-by-abstraction.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/branch-by-abstraction.html) |
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 APIs relacionadas con el componente de *notificaciones*. 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
![\[Descomposición de monolitos en microservicios utilizando el patrón de ramificación según abstracción\]](http://docs.aws.amazon.com/es_es/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/branch-by-abstraction.png)