El patrón estrangulador y las arquitecturas de vertical slices son dos herramientas que te permiten evolucionar una arquitectura limpia sin romper el sistema en producción. Aquí verás cómo aplicarlas, cuándo conviene mezclar estilos y por qué las métricas son tu mejor argumento frente a stakeholders no técnicos.
¿Qué es el patrón estrangulador en arquitectura de software?
El strangler fig es un patrón que reemplaza una implementación por otra completamente distinta sin afectar el sistema en ejecución [01:00]. La idea es sustituir gradualmente, no reescribir de golpe.
Imagina que tienes un componente altamente estable, pero íntimamente acoplado a una dependencia externa, como una base de datos. En lugar de reescribir toda la lógica desde el primer día, puedes seguir una secuencia paulatina:
- Separar comportamiento y dependencias en un nuevo componente.
- Cambiar primero las dependencias, manteniendo el comportamiento original.
- Reimplementar comportamientos manteniendo enlaces con la versión anterior.
- Cortar todos los lazos y deprecar el código legado.
¿Cuándo debo aplicar el patrón estrangulador? Cuando tienes código legado o componentes muy acoplados a dependencias externas, y necesitas evolucionar sin detener el sistema. Es ideal para metodologías ágiles porque enmascara la implementación anterior y la sustituye poco a poco.
Las métricas globales de arquitectura deberían reflejar cada uno de estos pasos, simplificando futuros cambios.
¿Cómo se compara la arquitectura limpia con vertical slices?
Una arquitectura limpia separa horizontalmente las capas: interfaces de usuario, servicios y modelos de dominio. Funciona muy bien al inicio, pero cuando crece el número de casos de uso, las dependencias empiezan a cruzarse [03:30].
En el ejemplo del Banco Interamericano de Desarrollo hay dos grupos de casos de uso, exportación e importación, y a medida que el sistema crece, las implementaciones originales necesitan repensarse. Aquí es donde aparece la tensión: aunque sigas buenas prácticas de separación y abstracción, leer un caso de uso completo se vuelve difícil para nuevos miembros del equipo.
¿Qué son las arquitecturas de vertical slices?
Las vertical slices, o tajadas de cebolla, agrupan por funcionalidad casos de uso completos con sus propios modelos, servicios, interfaces y adaptadores. En la práctica, encapsulas una arquitectura limpia dentro de cada caso de uso.
Esto trae ventajas claras:
- Aumenta la cohesión dentro de cada minicontexto.
- Promueve el trabajo en paralelo entre equipos.
- Reduce los tiempos de onboarding para nuevos desarrolladores.
¿Cuál es la desventaja de las vertical slices?
La principal contra es que rompes el principio don't repeat yourself (DRY). Vas a duplicar código entre casos de uso y necesitas validar la consistencia entre diseños. A cambio, ganas independencia y alta cohesión por slice.
¿Vertical slices o arquitectura limpia? No es una elección absoluta. La arquitectura limpia da pureza horizontal pero se vuelve difícil de leer con el tiempo. Los vertical slices dan independencia por caso de uso a costa de duplicación. El balance lo decides con métricas y según las capacidades del equipo.
¿Por qué las métricas son clave al negociar con stakeholders?
Las métricas de arquitectura te permiten negociar con product owners, product managers y otros perfiles no técnicos sobre prioridades de implementación [00:05]. Convierten una decisión técnica en un argumento cuantitativo.
Cuando combinas el patrón estrangulador con vertical slices, puedes ir migrando gradualmente una arquitectura limpia hacia tajadas verticales, midiendo el impacto en cada paso. Eso te da control sobre la deuda técnica y sobre la productividad del equipo.
La mezcla de estilos arquitectónicos preocupa a muchos arquitectos, pero la pureza de un estilo se pierde rápido y generalmente solo sirve para el papel. Lo que necesitas son guías, automatizaciones y métricas que garanticen calidad creciente.
¿Qué son los architectural decision records?
Los architectural decision records (ADR) documentan las decisiones que afectan al sistema a largo plazo. Son acumulativos y pueden cambiarse: no son dogmas. Esa flexibilidad es lo que permite a un equipo adaptarse al cambio sin perder consistencia.
La palabra clave aquí es consistencia. Si mantienes métricas de calidad a lo largo del tiempo, la entrada y salida de miembros del equipo, o los cambios en las condiciones del proyecto, no van a afectar dramáticamente tus decisiones previas.
¿Has aplicado el patrón estrangulador en algún proyecto legado? Cuéntame en los comentarios cómo manejaste la transición y qué métricas te resultaron más útiles.
