Software Architecture
Explica cómo reconocer, medir y priorizar deuda arquitectónica según impacto sobre cambios, fallos, operación y opciones futuras, y cómo reducirla incrementalmente.
La deuda arquitectónica no es simplemente código feo. Es una decisión estructural que aumenta el costo, el riesgo o la lentitud de cambios futuros. Puede aceptarse conscientemente, pero necesita alcance, interés observable y una condición de revisión.
La metáfora de deuda resulta útil cuando distingue:
decisión temporal
→ entrega o aprendizaje más rápido
→ costo recurrente durante cambios y operación
→ pago, refinanciación o aceptaciónNo toda imperfección es deuda. Una solución sencilla que cumple drivers y no bloquea evolución puede ser adecuada. Llamarla deuda solo porque no utiliza el patrón preferido confunde calidad con gusto personal.
Los equipos necesitan hablar de compromisos técnicos sin convertir toda conversación en “reescribir” o “dejar como está”.
Ejemplos reales de deuda arquitectónica:
El concepto permite registrar por qué se tomó la decisión, qué costo genera y cuándo dejará de ser aceptable.
El equipo conoce el compromiso:
Usaremos una base compartida durante validación.
El ownership se mantendrá por módulos.
Revisaremos al superar 500 tenants o requerir restore individual.Existe una razón, límites y trigger.
Se reconoce el problema, pero no se evalúa el daño: “No hay tiempo; después vemos”. No existe estrategia de salida.
El equipo descubre más tarde que la decisión era débil porque aprendió sobre el dominio, la escala o la tecnología. No toda deuda es negligencia.
Una solución correcta deja de ser adecuada porque cambian drivers: más equipos, regulación, volumen o dependencia comercial.
La clasificación ayuda a evitar culpabilizar retrospectivamente decisiones razonables.
Afecta un componente o flujo. Puede corregirse mediante refactor acotado.
Atraviesa datos, contratos, despliegues, equipos y operación. Necesita una migración por etapas.
Ejemplo: renombrar una clase es local. Cambiar ownership de Inventario desde tablas compartidas hacia una API o módulo único es sistémico.
La deuda arquitectónica se observa mediante comportamiento, no solo mediante diagramas.
Una funcionalidad pequeña modifica muchos módulos y equipos.
Componentes supuestamente independientes siempre deben publicarse juntos.
La misma frontera produce fugas, estados inconsistentes o saturación.
El equipo dedica más tiempo a comprender impacto, preparar ambientes y coordinar cambios.
Áreas sin pruebas ni ownership se evitan, incluso cuando el negocio necesita cambios.
Varias fuentes de verdad o reglas repetidas generan reconciliación manual.
Fitness functions, permisos o procesos acumulan bypasses.
Un ítem útil contiene:
Título: Payments SDK filtrado en dominio
Contexto: integración inicial rápida
Decisión actual: tipos del proveedor usados en casos de uso
Interés: cada cambio de proveedor toca 14 módulos
Riesgo: bloqueo comercial y errores de migración
Trigger: segundo proveedor o aumento de tarifas > 20 %
Estrategia: introducir PaymentPort y adapter
Evidencia: mapa de imports y cambios recientes
Owner: PaymentsEvita tickets como “mejorar arquitectura” o “refactor general”. No permiten estimar valor ni comprobar cierre.
No toda deuda debe pagarse inmediatamente.
Evalúa:
Una matriz simple:
alto interés + alto riesgo
→ prioridad alta
alto interés + bajo riesgo
→ mejorar junto con cambios frecuentes
bajo interés + alto riesgo
→ mitigación, observabilidad y plan
bajo interés + bajo riesgo
→ aceptar y revisar despuésPagar deuda por “pureza” puede consumir recursos sin mejorar el producto.
Un refactor conserva el comportamiento externo relevante mientras cambia estructura. A escala arquitectónica puede requerir periodos donde existen dos caminos.
Antes de modificar un sistema poco entendido, captura su comportamiento actual.
No todo comportamiento es correcto, pero conocerlo evita cambios accidentales. Separa:
Un seam es un punto donde una implementación puede sustituirse sin modificar todo el sistema.
Ejemplo:
controladores → SDK de pago directoPaso intermedio:
controladores → PaymentFacade → SDK actualDespués:
casos de uso → PaymentPort → Adapter actual / Adapter nuevoLa fachada inicial permite centralizar sin una reescritura inmediata.
En lugar de mantener una rama larga:
Reduce divergencia y permite integración continua, pero la abstracción temporal también necesita fecha de eliminación.
Útil para datos y contratos:
No elimines una columna en el mismo despliegue que cambia todos los lectores si existen versiones concurrentes.
Para un monolito sin límites:
El objetivo inicial no tiene que ser extraer microservicios. Un monolito modular puede eliminar gran parte del interés.
Situación:
inventory_stock directamente.Interés:
Migración:
reserve, release, receive.La deuda se considera pagada cuando las escrituras están controladas y la evidencia demuestra ownership, no cuando se mueve código de carpeta.
Una reescritura puede parecer más limpia porque evita restricciones del sistema existente. Sus riesgos:
Puede justificarse si la plataforma actual impide cualquier evolución, el alcance está bien delimitado y existe estrategia de transición. Aun así, la migración de usuarios, datos e integraciones sigue siendo el problema principal.
No es necesario reservar un porcentaje fijo universal. Integra el pago con el trabajo que genera valor:
También puede ser necesario un proyecto dedicado cuando la deuda sistémica bloquea múltiples iniciativas.
Contar líneas refactorizadas no demuestra mejora arquitectónica.
La edad no determina adecuación. Evalúa costo y riesgo.
Sin contexto, una decisión razonable parece incompetencia. Conserva la razón.
“Más adelante” no es una estrategia. Define señales.
La migración queda permanente y aumenta complejidad.
El equipo no puede distinguir cambio estructural de regresión.
Conecta el trabajo con velocidad, riesgo, disponibilidad o costo.
Migraciones arquitectónicas y Strangler Fig desarrolla cómo mover comportamiento, datos y tráfico sin depender de un reemplazo de tipo big bang.