Arquitectura de software: Las partes difíciles

Capítulo 4. Descomposición arquitectónica

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Monday, October 4, 10:04

Ahora que Addison y Austen tenían luz verde para pasar a una arquitectura distribuida y separar la aplicación monolítica Sysops Squad, necesitaban determinar el mejor enfoque para empezar.

"La aplicación es tan grande que no sé ni por dónde empezar. Es tan grande como un elefante!", exclamó Addison.

"Bueno", dijo Austen. "¿Cómo se come un elefante?".

"Ja, ya he oído ese chiste antes, Austen. Un bocado cada vez, claro", se rió Addison.

"Exacto. Así que utilicemos el mismo principio con la aplicación Escuadrón Sysops", dijo Austen. "¿Por qué no empezamos a desmenuzarla, bocado a bocado? ¿Recuerdas que dije que los informes eran una de las causas del bloqueo de la aplicación? Quizá deberíamos empezar por ahí".

"Eso podría ser un buen comienzo", dijo Addison, "pero ¿qué pasa con los datos? Hacer de los informes un servicio independiente no resuelve el problema. Tendríamos que separar también los datos, o incluso crear una base de datos de informes independiente con bombas de datos para alimentarla. Creo que es un bocado demasiado grande para empezar".

"Tienes razón", dijo Austen. "Oye, ¿y la funcionalidad de la base de conocimientos? Es bastante independiente y podría ser más fácil de extraer".

"Es cierto. ¿Y qué hay de la funcionalidad de la encuesta? Eso también debería ser fácil de separar", dijo Addison. "El problema es que no puedo evitar sentir que deberíamos abordar esto con un enfoque más metódico, en lugar de comernos el elefante bocado a bocado".

"Quizá Logan pueda darnos algún consejo", dijo Austen.

Addison y Austen se reunieron con Logan para discutir algunos de los enfoques que estaban considerando sobre cómo dividir la aplicación. Explicaron a Logan que querían empezar con la base de conocimientos y la funcionalidad de encuestas, pero no estaban seguros de qué hacer después.

"El enfoque que sugieres -dijo Logan- es lo que se conoce como el Antipatrón de la Migración del Elefante. Comerse el elefante de bocado en bocado puede parecer un buen planteamiento al principio, pero en la mayoría de los casos conduce a un enfoque desestructurado que da lugar a una gran bola de barro distribuido, lo que algunos llaman también un monolito distribuido. Yo no recomendaría ese enfoque".

"Entonces, ¿qué otros enfoques existen? ¿Existen patrones que podamos utilizar para desmenuzar la aplicación?", preguntó Addison.

"Tienes que adoptar una visión holística de la aplicación y aplicar la bifurcación táctica o la descomposición basada en componentes", dice Logan. "Son los dos enfoques más eficaces que conozco".

Addison y Austen miraron a Logan. "¿Pero cómo sabremos cuál usar?".

---

Mientras que la modularidad arquitectónica describe el porqué de separar una aplicación monolítica, la descomposición arquitectónica de describe el cómo. Descomponer aplicaciones monolíticas grandes y complejas puede ser una empresa compleja y lenta, y es importante saber si es siquiera factible iniciar ese esfuerzo y cómo abordarlo.

La descomposición basada en componentes y la bifurcación táctica son dos enfoques habituales de para descomponer aplicaciones monolíticas. La descomposición basada en componentes es un enfoque de extracción que aplica varios patrones de refactorización para refinar y extraer componentes (los bloques lógicos de una aplicación) para formar una arquitectura distribuida de forma incremental y controlada. El enfoque de bifurcación táctica consiste en hacer réplicas de una aplicación y desmenuzar las partes no deseadas para formar servicios, de forma similar a como un escultor crea una bella obra de arte a partir de un bloque de granito o mármol.

¿Qué enfoque es más eficaz? La respuesta a esta pregunta es, por supuesto, depende. Uno de los principales factores a la hora de seleccionar un enfoque de descomposición es lo bien estructurado que esté el código de la aplicación monolítica existente. ¿Existen componentes y límites de componentes claros dentro del código base, o es éste en gran medida una gran bola de barro desestructurada?

Como ilustra el diagrama de flujo de la Figura 4-1, el primer paso en un esfuerzo de descomposición de la arquitectura es determinar primero si el código base es siquiera descomponible. Trataremos este tema en detalle en la siguiente sección. Si el código base es descomponible, el siguiente paso es determinar si el código fuente es en gran parte un lío desestructurado sin componentes claramente definibles. Si es así, la bifurcación táctica (ver "Bifurcación táctica") es probablemente el enfoque adecuado. Sin embargo, si los archivos de código fuente están estructurados de forma que combinan funciones similares dentro de componentes bien definidos (o incluso vagamente definidos), entonces lo que hay que hacer es una descomposición basada en componentes (ver "Descomposición basada en componentes").

Figura 4-1. Árbol de decisión para elegir un método de descomposición

Describimos ambos enfoques en este capítulo, y luego dedicamos un capítulo entero(Capítulo 5) a describir detalladamente cada uno de los patrones de descomposición basados en componentes.

¿Es descomponible el código base?

¿Qué ocurre cuando un código base carece de estructura interna? ¿Puede incluso descomponerse? Este tipo de software tiene un nombre coloquial: el antipatrón de la Gran Bola de Barro, acuñado por Brian Foote en un ensayo del mismo nombre en 1999. Por ejemplo, una aplicación web compleja con manejadores de eventos conectados directamente a llamadas a la base de datos y sin modularidad puede considerarse una arquitectura Big Ball of Mud. Por lo general, los arquitectos no dedican mucho tiempo a crear patrones para este tipo de sistemas; la arquitectura del software tiene que ver con la estructura interna, y estos sistemas carecen de esa característica definitoria.

Por desgracia, sin una gobernanza cuidadosa, muchos sistemas de software se degradan hasta convertirse en grandes bolas de barro, dejando su reparación en manos de arquitectos posteriores (o quizá de un antiguo yo despreciado). El primer paso en cualquier ejercicio de reestructuración de la arquitectura requiere que un arquitecto determine un plan para la reestructuración, lo que a su vez requiere que el arquitecto comprenda la estructura interna. La pregunta clave que debe responder el arquitecto es: ¿es salvable esta base de código? En otras palabras, ¿es candidata a los patrones de descomposición, o es más apropiado otro enfoque?

Ninguna medida por sí sola determinará si una base de código tiene una estructura interna razonable: esa evaluación corresponde determinarla a uno o varios arquitectos. Sin embargo, los arquitectos disponen de herramientas para ayudar a determinar las macrocaracterísticas de una base de código, en particular las métricas de acoplamiento, para ayudar a evaluar la estructura interna.

Acoplamiento aferente y eferente

En 1979, Edward Yourdon y Larry Constantine publicaron Diseño Estructurado: Fundamentos de una disciplina de diseño de programas y sistemas informáticos (Yourdon), en el que se definen muchos conceptos básicos, entre ellos las métricas de acoplamiento aferente y eferente. El acoplamiento aferente mide el número de conexiones entrantes a un artefacto de código (componente, clase, función, etc.). El acoplamiento eferente mide las conexiones salientes a otros artefactos de código.

Observa el valor de sólo estas dos medidas al cambiar la estructura de un sistema. Por ejemplo, al deconstruir un monolito en una arquitectura distribuida, un arquitecto encontrará clases compartidas como Address. Al construir un monolito, es habitual y se anima a los desarrolladores a reutilizar conceptos básicos como Address, pero al desmontar el monolito, ahora el arquitecto debe determinar cuántas otras partes del sistema utilizan este recurso compartido.

Prácticamente todas las plataformas disponen de herramientas que permiten a los arquitectos analizar las características de acoplamiento del código para ayudarles a reestructurar, migrar o comprender una base de código. Existen muchas herramientas para diversas plataformas que proporcionan una vista matricial de las relaciones entre clases y/o componentes, como se ilustra en la Figura 4-2.

En este ejemplo, el complemento de Eclipse proporciona una visualización del resultado de JDepend, que incluye el análisis de acoplamiento por paquete, junto con algunas métricas agregadas que se destacan en la siguiente sección.

Figura 4-2. Vista de análisis de JDepend en Eclipse de las relaciones de acoplamiento

Abstracción e inestabilidad

Robert Martin, una figura muy conocida en el mundo de la arquitectura de software , creó unas métricas derivadas para un libro de C++ a finales de los 90 que son aplicables a cualquier lenguaje orientado a objetos. Estas métricas -abstracción e inestabilidad- miden el equilibrio de las características internas de una base de código.

La abstracción es la relación entre artefactos abstractos (clases abstractas, interfaces, etc.) y artefactos concretos (clases de implementación). Representa una medida de la abstracción frente a la implementación. Los elementos abstractos son características de una base de código que permiten a los desarrolladores comprender mejor la función global. Por ejemplo, una base de código formada por un único método main() y 10.000 líneas de código tendría una puntuación de casi cero en esta métrica y sería bastante difícil de entender.

La fórmula de la abstracción aparece en la Ecuación 4-1.

Ecuación 4-1. Abstracción

$$A=\frac{\sum m^a}{\sum m^c+\sum m^a}$$

En la ecuación $m^a$ representa los elementos abstractos (interfaces o clases abstractas) dentro de la base de código, y $m^c$ representa los elementos concretos. Los arquitectos calculan la abstracción calculando la relación entre la suma de artefactos abstractos y la suma de los concretos.

Otra métrica derivada, la inestabilidad, es la relación entre el acoplamiento eferente y la suma del acoplamiento eferente y aferente, que se muestra en la ecuación 4-2.

Ecuación 4-2. Inestabilidad

$$I=\frac{C^e}{C^e+C^a}$$

En la ecuación $C^e$ representa el acoplamiento eferente (o saliente) , y $C^a$ representa el acoplamiento aferente (o entrante).

La métrica de inestabilidad determina la volatilidad de una base de código. Una base de código que presenta altos grados de inestabilidad se rompe más fácilmente cuando se modifica, debido a su elevado acoplamiento. Considera dos escenarios, cada uno con $C^a$ de 2. Para el primer escenario $C^e$ = 0, lo que da una puntuación de inestabilidad de cero. En el otro escenario $C^e$ = 3, se obtiene una puntuación de inestabilidad de 3/5. Así, la medida de inestabilidad de un componente refleja cuántos cambios potenciales podrían verse forzados por cambios en componentes relacionados. Un componente con un valor de inestabilidad cercano a uno es altamente inestable, un valor cercano a cero puede ser estable o rígido: es estable si el módulo o componente contiene mayoritariamente elementos abstractos, y rígido si comprende mayoritariamente elementos concretos. Sin embargo, la contrapartida de una alta estabilidad es la falta de reutilización: si cada componente es autónomo, es probable que se duplique.

Un componente con un valor de I cercano a 1, podemos estar de acuerdo, es altamente inestable. Sin embargo, un componente con un valor de I próximo a 0 puede ser estable o rígido. Sin embargo, si contiene mayoritariamente elementos de hormigón, entonces es rígido.

Así pues, en general, es importante considerar el valor de I y A conjuntamente y no de forma aislada. De ahí la razón para considerar la secuencia principal que se presenta en la página siguiente.

Distancia de la secuencia principal

Una de las pocas métricas holísticas que tienen los arquitectos para la estructura arquitectónica es la distancia a la secuencia principal, una métrica derivada basada en la inestabilidad y la abstracción, que se muestra en la Ecuación 4-3.

Ecuación 4-3. Distancia de la secuencia principal

$$D=|A+I-1|$$

En la ecuación, A = abstracción e I = inestabilidad.

La métrica de la distancia a la secuencia principal imagina una relación ideal entre abstracción e inestabilidad; los componentes que caen cerca de esta línea idealizada muestran una mezcla saludable de estas dos preocupaciones contrapuestas. Por ejemplo, el gráfico de un componente concreto permite a los desarrolladores calcular la métrica de la distancia a la secuencia principal, ilustrada en la Figura 4-3.

Figura 4-3. Distancia normalizada a la secuencia principal para un componente concreto

Los desarrolladores grafican el componente candidato y luego miden la distancia a la línea idealizada. Cuanto más se acerque a la línea, mejor equilibrado estará el componente. Los componentes que caen demasiado lejos de la esquina superior derecha entran en lo que los arquitectos llaman la zona de la inutilidad: el código demasiado abstracto se vuelve difícil de usar. A la inversa, el código que cae en la esquina inferior izquierda entra en la zona del dolor: el código con demasiada implementación y poca abstracción se vuelve quebradizo y difícil de mantener, como se ilustra en la Figura 4-4.

Existen herramientas en muchas plataformas para proporcionar estas medidas, que ayudan a los arquitectos cuando analizan bases de código por desconocimiento, migración oevaluación de la deuda técnica.

¿Qué dice la métrica de la distancia a la secuencia principal a los arquitectos que quieren reestructurar aplicaciones? Al igual que en los proyectos de construcción, mover una gran estructura que tiene unos cimientos deficientes presenta riesgos. Del mismo modo, si un arquitecto aspira a reestructurar una aplicación, mejorar la estructura interna facilitará el traslado de laentidad.

Figura 4-4. Zonas de inutilidad y dolor

Esta métrica también proporciona una buena pista sobre el equilibrio de la estructura interna. Si un arquitecto evalúa una base de código en la que muchos de los componentes caen en las zonas de la inutilidad o del dolor, quizá no sea un buen uso del tiempo intentar apuntalar la estructura interna hasta el punto en que pueda repararse.

Siguiendo el diagrama de flujo de la Figura 4-1, una vez que un arquitecto decide que el código base es descomponible, el siguiente paso es determinar qué enfoque adoptar para descomponer la aplicación. En los siguientes apartados se describen los dos enfoques para descomponer una aplicación: la descomposición basada en componentes y la bifurcación táctica.

Descomposición por componentes

Según nuestra experiencia, la mayor parte de la dificultad y complejidad que entraña la migración de aplicaciones monolíticas a una arquitectura altamente distribuida, como los microservicios, proviene de componentes arquitectónicos mal definidos. Aquí definimos un componente como un bloque de construcción de la aplicación que tiene un papel y una responsabilidad bien definidos en el sistema y un conjunto bien definido de operaciones. En la mayoría de las aplicaciones, los componentes se manifiestan a través de espacios de nombres o estructuras de directorios y se implementan mediante archivos de componentes (o archivos fuente). Por ejemplo, en la Figura 4-5, la estructura de directorios penultimate/ss/ticket/assign representaría un componente llamado Ticket Assign con el espacio de nombres penultimate.ss.ticket.assign.

Figura 4-5. La estructura de directorios de una base de código se convierte en el espacio de nombres delcomponente

Consejo

Cuando descompongas aplicaciones monolíticas en arquitecturas distribuidas, construye servicios a partir de componentes, no de clases individuales.

A lo largo de muchos años colectivos de migración de aplicaciones monolíticas a arquitecturas distribuidas (como los microservicios), hemos desarrollado un conjunto de patrones de descomposición basados en componentes, descritos en el Capítulo 5, que ayudan a preparar una aplicación monolítica para la migración. Estos patrones implican la refactorización del código fuente para llegar a un conjunto de componentes bien definidos que, con el tiempo, pueden convertirse en servicios, facilitando el esfuerzo necesario para migrar aplicaciones a arquitecturas distribuidas.

Estos patrones de descomposición basados en componentes permiten esencialmente la migración de una arquitectura monolítica a una arquitectura basada en servicios, que se define en el Capítulo 2 y se describe con más detalle en Fundamentos de la Arquitectura del Software. La arquitectura basada en servicios es un híbrido del estilo de arquitectura de microservicios en el que una aplicación se divide en servicios de dominio, que son servicios de grano grueso, desplegados por separado, que contienen toda la lógica empresarial de un dominio concreto.

Pasar a una arquitectura basada en servicios es adecuado como objetivo final o como paso previo a los microservicios:

• Como piedra angular, permite a un arquitecto determinar qué dominios requieren más niveles de granularidad en microservicios y cuáles pueden permanecer como servicios de dominio de granularidad gruesa (esta decisión se trata en detalle en el Capítulo 7).

• La arquitectura basada en servicios no requiere descomponer la base de datos, por lo que permite a los arquitectos centrarse en el dominio y en la partición funcional antes de abordar la descomposición de la base de datos (tratada en detalle en el Capítulo 6).

• La arquitectura basada en servicios no requiere ninguna automatización operativa ni contenerización. Cada servicio de dominio puede desplegarse utilizando el mismo artefacto de implementación que la aplicación original (como un archivo EAR, WAR, ensamblado, etc.).

• El paso a la arquitectura basada en servicios es técnico, lo que significa que generalmente no implica a las partes interesadas de la empresa y no requiere ningún cambio en la estructura organizativa del departamento de TI ni en losentornos de pruebas e implementación.

Consejo

Al migrar aplicaciones monolíticas a microservicios, considera la posibilidad de pasar primero a una arquitectura basada en servicios como paso previo a los microservicios.

Pero, ¿y si la base de código es una gran bola de barro desestructurada y no contiene muchos componentes observables? Ahí es donde entra en juego la bifurcación táctica.

Bifurcación táctica

El patrón de bifurcación táctica fue bautizado por Fausto De La Torre como un enfoque pragmático para reestructurar arquitecturas que son básicamente grandes bolas de barro.

Generalmente, cuando los arquitectos piensan en reestructurar una base de código, piensan en extraer trozos, como se ilustra en la Figura 4-6.

Figura 4-6. Extraer una parte de un sistema

Sin embargo, otra forma de pensar en aislar una parte de un sistema consiste en eliminar las partes que ya no se necesitan, como se ilustra en la Figura 4-7.

Figura 4-7. Borrar lo que no se quiere es otra forma de aislar partes de un sistema

En la Figura 4-6, los desarrolladores tienen que lidiar constantemente con los exuberantes hilos de acoplamiento que definen esta arquitectura; a medida que extraen trozos, descubren que cada vez debe haber más del monolito debido a las dependencias. En la Figura 4-7, los desarrolladores eliminan el código que no es necesario, pero las dependencias permanecen, evitando el constante efecto desenredante de la extracción.

La diferencia entre extracción y eliminación inspira el patrón de bifurcación táctica. Para este enfoque de descomposición, el sistema comienza como una única aplicación monolítica, como se muestra en la Figura 4-8.

Figura 4-8. Antes de reestructurarse, un monolito incluye varias partes

Este sistema consta de varios comportamientos de dominio (identificados en la figura como formas geométricas simples) sin mucha organización interna. Además, en este escenario, el objetivo deseado consiste en que dos equipos creen dos servicios, uno con el dominio hexágono y cuadrado, y otro con el dominio círculo, a partir del monolito existente.

El primer paso de la bifurcación táctica consiste en clonar todo el monolito y dar a cada equipo una copia de todo el código base, como se ilustra en la Figura 4-9.

Figura 4-9. El primer paso clona el monolito

Cada equipo recibe una copia de toda la base de código, y empiezan a eliminar (como se ilustra anteriormente en la Figura 4-7) el código que no necesitan en lugar de extraer el código deseable. Los desarrolladores suelen encontrar esto más fácil en una base de código estrechamente acoplada, porque no tienen que preocuparse de extraer el gran número de dependencias que crea el alto acoplamiento. En cambio, en la estrategia de eliminación, una vez aislada la funcionalidad, elimina todo el código que no rompa nada.

A medida que avanza el patrón, los equipos empiezan a aislar las partes objetivo, como se muestra en la Figura 4-10. Después, cada equipo continúa la eliminación gradual del código no deseado.

Figura 4-10. Los equipos refactorizan constantemente para eliminar el código no deseado

Al finalizar el patrón de bifurcación táctica, los equipos han dividido la aplicación monolítica original en dos partes, conservando la estructura de grano grueso del comportamiento en cada parte, como se ilustra en la Figura 4-11.

Figura 4-11. El estado final de la bifurcación táctica presenta dos servicios

Ahora se ha completado la reestructuración, dejando como resultado dos servicios de grano grueso.

Contrapartidas

La bifurcación táctica es una alternativa viable a un enfoque de descomposición más formal , más adecuado para bases de código que tienen poca o ninguna estructura interna. Como todas las prácticas de arquitectura, tiene su parte de compensaciones:

Beneficios

• Los equipos pueden empezar a trabajar de inmediato sin apenas análisis previos.

• A los desarrolladores les resulta más fácil borrar código que extraerlo. Extraer código de una base de código caótica presenta dificultades debido al alto acoplamiento, mientras que el código que no se necesita puede verificarse mediante compilación o pruebas sencillas.

Deficiencias

• Es probable que los servicios resultantes sigan conteniendo una gran cantidad de código, en su mayor parte latente, sobrante del monolito.

• A menos que los desarrolladores realicen esfuerzos adicionales, el código de los nuevos servicios derivados no será mejor que el código caótico del monolito, simplemente habrá menos.

• Pueden producirse incoherencias entre la denominación del código compartido y los archivos de componentes compartidos, lo que dificulta la identificación del código común y sucoherencia.

El nombre de este patrón es acertado (como deberían serlo todos los buenos nombres de patrones): proporciona un enfoque táctico más que estratégico para reestructurar arquitecturas, permitiendo a los equipos migrar rápidamente sistemas importantes o críticos a la siguiente generación (aunque de forma no estructurada).

Saga Sysops Squad: Elegir un enfoque de descomposición

Friday, October 29, 10:01

Ahora que Addison y Austen comprendían ambos enfoques, se reunieron en la sala de conferencias principal para analizar la aplicación Sysops Squad utilizando las métricas de abstracción e inestabilidad para determinar qué enfoque sería el más adecuado dada su situación.

"Mira esto", dijo Addison. "La mayor parte del código se encuentra a lo largo de la secuencia principal. Hay algunos valores atípicos, por supuesto, pero creo que podemos concluir que es factible dividir esta aplicación. Así que el siguiente paso es determinar qué enfoque utilizar".

"Me gusta mucho el enfoque de la bifurcación táctica", dijo Austen. "Me recuerda a los escultores famosos, cuando se les preguntaba cómo eran capaces de esculpir obras tan bellas en mármol macizo, que respondían que se limitaban a quitar el mármol que se suponía que no debía estar ahí. Siento que la aplicación Escuadrón Sysops podría ser mi escultura".

"Un momento, Miguel Ángel", dijo Addison. "¿Primero el deporte y ahora la escultura? Tienes que decidir en qué te gusta emplear tu tiempo no laboral. Lo que no me gusta del enfoque de bifurcación táctica es todo el código duplicado y la funcionalidad compartida dentro de cada servicio. La mayoría de nuestros problemas tienen que ver con la mantenibilidad, la comprobabilidad y la fiabilidad general. ¿Te imaginas tener que aplicar el mismo cambio a varios servicios diferentes al mismo tiempo? Sería una pesadilla".

"¿Pero cuánta funcionalidad compartida hay realmente?", preguntó Austen.

"No estoy seguro", dijo Addison, "pero sé que hay bastante código compartido para las cosas de infraestructura como el registro y la seguridad, y sé que muchas de las llamadas a la base de datos se comparten desde la capa de persistencia de la aplicación".

Austen hizo una pausa y pensó un poco en el argumento de Addison. "Quizá tengas razón. Como ya tenemos definidos unos buenos límites de componentes, me parece bien hacer el enfoque de descomposición más lento basado en componentes y renunciar a mi carrera de escultor. Pero no renunciaré a los deportes".

Addison y Austen llegaron al acuerdo de que el enfoque de descomposición por componentes sería el adecuado para la aplicación Sysops Squad. Addison redactó un ADR para esta decisión, en el que esbozaba las ventajas y desventajas y la justificación del enfoque de descomposición por componentes.

ADR: Migración mediante el método de descomposición por componentes

Contexto
Vamos a descomponer la aplicación monolítica Sysops Squad en servicios de implementación independiente. Los dos enfoques que consideramos para la migración a una arquitectura distribuida fueron la bifurcación táctica y la descomposición basada en componentes.

Decisión
Utilizaremos el enfoque de descomposición basado en componentes para migrar la actual aplicación monolítica Sysops Squad a una arquitectura distribuida.

La aplicación tiene límites de componentes bien definidos, lo que se presta al enfoque de descomposición basado en componentes.

Este enfoque reduce la posibilidad de tener que mantener código duplicado dentro de cadaservicio.

Con el enfoque de bifurcación táctica, tendríamos que definir los límites del servicio por adelantado para saber cuántas aplicaciones bifurcadas crear. Con el enfoque de descomposición basado en componentes, las definiciones de servicio surgirán de forma natural mediante la agrupación de componentes.

Dada la naturaleza de los problemas a los que nos enfrentamos con la aplicación actual en cuanto a fiabilidad, disponibilidad, escalabilidad y flujo de trabajo, utilizar el enfoque de descomposición basado en componentes proporciona una migración incremental más segura y controlada que el enfoque de bifurcación táctica.

Consecuencias
Es probable que el esfuerzo de migración lleve más tiempo con el enfoque de descomposición basado en componentes que con la bifurcación táctica. Sin embargo, creemos que las justificaciones de la sección anterior compensan esta desventaja.

Este enfoque permite a los desarrolladores del equipo trabajar en colaboración para identificar la funcionalidad compartida, los límites de los componentes y los límites del dominio. La bifurcación táctica nos obligaría a dividir el equipo en equipos más pequeños y separados para cada aplicación bifurcada, y aumentaría la coordinación necesaria entre los equipos más pequeños.