Modifiability

Intención y unidad de evaluación

Modifiability describe el costo y riesgo de modificar un sistema para satisfacer un cambio concreto. La evaluación identifica qué cambia, bajo qué condiciones y quién realiza el trabajo. El informe Modifiability Tactics, SEI relaciona cambios previstos, responsabilidades, coupling, cohesion y costo; «ser modificable» sin especificar la modificación deja demasiado margen para decidir.

En el Atlas, el costo incluye esfuerzo, tiempo transcurrido, coordinación, conocimiento especializado, validación y consecuencias de deployment. El riesgo incluye regresiones e incertidumbre sobre dependencias afectadas. Contar líneas editadas puede describir parte del trabajo, pero no demuestra facilidad: modificar una línea de un contrato público puede exigir semanas de coordinación.

La pregunta arquitectónica es qué decisiones hacen que una variación relevante permanezca local o atraviese fronteras. architectural-drivers conecta esa preocupación con objetivos; quality-attribute-scenarios permite acordar respuesta y medida. No buscamos un puntaje abstracto que compare cualquier sistema contra cualquier cambio.

Estímulos, entornos y medidas

Una solicitud de producto puede introducir otro proveedor de pagos; una dependencia puede retirar una API; una regulación puede cambiar una regla compartida. El artifact puede ser un módulo, contrato, integración o conjunto de capacidades. Un cambio durante desarrollo normal tiene condiciones diferentes de una corrección urgente en producción.

La respuesta comprende entender, modificar, revisar y validar, y puede incluir desplegar. Medidas útiles registran esfuerzo total, elementos afectados, equipos coordinados, tiempo de espera y regresiones. Deben indicar qué trabajo cuentan y qué evidencia acepta el stakeholder. Los mismos resultados pueden ser adecuados para una migración anual y excesivos para una variación semanal.

Este documento usa ejemplos propios de integración de pagos para razonar sobre esas decisiones. Sus fronteras y presupuestos son acuerdos ilustrativos, no mediciones del Atlas ni umbrales universales.

Change propagation

El riesgo central es que una modificación obligue a otras que no parecían parte de la necesidad inicial:

Change in A
    ↓
B must change
    ↓
C must change
    ↓
tests / configuration / deployment must change

En nuestro ejemplo, cambiar una representación del proveedor en A exige adaptar un cálculo en B, una respuesta pública en C y consumidores externos. El radio de propagación incluye pruebas, configuración y delivery; mirar únicamente los imports omite dependencias semánticas.

Un schema compartido puede comunicar estructura, pero también expectativas sobre significado, orden o valores posibles. Una dependencia oculta aparece cuando un consumidor interpreta un código propietario sin declararlo en su contrato. Si varias áreas duplican conocimiento sobre una única política, corregirla exige descubrir todas sus copias. Una firma que no cambia tampoco demuestra compatibilidad de comportamiento.

El modelo de SEI sobre modifiability incluye costo directo y cambios propagados entre responsabilidades. Su interés está en cómo las relaciones amplían el trabajo, no en convertir número de archivos o cantidad de servicios en una medida suficiente.

Cohesion, coupling y decisiones volátiles

Agrupar responsabilidades que cambian por la misma razón puede mantener una modificación dentro de un límite entendible. Controlar dependencias evita que decisiones locales se vuelvan obligaciones de todo el sistema. Cohesion y coupling son fuerzas relativas al cambio esperado; una unidad que concentra todo el producto puede tener cercanía física y poca localidad conceptual.

Reducir coupling indiscriminadamente también cuesta. Más intermediarios pueden introducir traducciones, contratos, navegación y propietarios adicionales. Separar dos responsabilidades que siempre necesitan cambiar conjuntamente puede aumentar coordinación. El diseño necesita explicar qué dependencia reduce y por qué ese beneficio compensa la nueva estructura.

Parnas propone organizar módulos alrededor de decisiones difíciles o susceptibles de cambiar, ocultándolas del resto en On the Criteria To Be Used in Decomposing Systems into Modules. La aplicación aquí es proteger variación independiente, no esconder toda información.

Payment capability
    ↓
Stable application boundary
    ↓
Provider-specific detail

Si autorización y liquidación varían entre proveedores, el límite debe expresar esas obligaciones sin exponer su SDK. Ocultar una diferencia de negocio relevante detrás de un contrato demasiado pobre puede trasladar el problema a errores o condiciones especiales dispersas.

Decisiones enfocadas y evidencia

architectural-tactics permite tratar cada movimiento como hipótesis. Para un proveedor intercambiable, encapsular traducciones busca reducir cambios en consumidores; el costo son mappings y pruebas del contrato. La evidencia sería una incorporación representativa con consumidores preservados, no la existencia de una interfaz.

Para una política que cambia como unidad, localizar su conocimiento busca evitar correcciones divergentes; el costo puede ser una dependencia común. Restringir acceso a detalles privados busca limitar propagación; mantener esa restricción requiere revisión y mecanismos del lenguaje. Introducir indirection permite sustituir una colaboración, pero agrega recorrido y un contrato que también puede cambiar.

Estas alternativas dependen del escenario. Si la variación todavía es hipotética, diseñar una plataforma genérica de proveedores puede consumir más esfuerzo que el cambio futuro. quality-attribute-trade-offs examina preparación inicial, costo posterior y efectos sobre otras qualities.

Relaciones con patrones y profiles

ports-and-adapters puede proteger lógica de aplicación cuando tecnologías externas cambian independientemente. El artículo original de Cockburn separa conversaciones de aplicación y adaptadores tecnológicos. En nuestra comparación, un SQL Adapter que satisface un Application Port reduce exposición al driver; sustituirlo sigue exigiendo comprobar transacciones y errores. Ports amplios, inestables o que filtran tipos externos debilitan el beneficio.

Un modular-monolith puede localizar cambios mediante encapsulación, contratos y ownership. modularity desarrolla esas propiedades y exige contrastarlas con dependencias y accesos reales. Un proveedor nuevo puede afectar un módulo y aun requerir desplegar el conjunto. Esa diferencia conecta con deployability: localidad del cambio y granularidad de entrega deben evaluarse por separado.

microservices puede localizar implementación y ownership, pero una feature que atraviesa contratos, schemas, equipos y despliegues puede necesitar más coordinación. Más servicios no implica mayor modifiability. Para vertical-slice-architecture, Bogard propone organizar alrededor del eje de cambio del caso de uso. La localidad ayuda si la variación se alinea con features; carpetas verticales con coupling global no aseguran esa respuesta.

Escenario: incorporar un proveedor

Campo	Escenario propio
Source	Equipo de producto.
Stimulus	Solicita soporte para un nuevo proveedor de pagos con capacidades compatibles con el contrato previsto.
Artifact	Área de integración de pagos y consumidores de su contrato.
Environment	Desarrollo normal, contrato del proveedor accesible, entorno de pruebas y equipo disponible.
Response	Ingeniería implementa y valida la integración preservando el comportamiento de los proveedores existentes.
Response Measure	Cambio localizado dentro de la frontera acordada, sin editar implementaciones de proveedores anteriores y dentro del esfuerzo de ingeniería convenido.

Evaluarlo exige acordar la frontera antes del cambio, qué tareas integran el esfuerzo y qué pruebas representan preservación. Composición y configuración pueden necesitar cambios dentro de ese límite. El historial de archivos, revisiones, pruebas y horas de trabajo ofrecen evidencia complementaria; ausencia de cambios en proveedores viejos no prueba ausencia de regresiones.

Si el proveedor incorpora una obligación que el contrato actual no puede expresar, cambió un supuesto. Hay que revisar el escenario y sus expectativas, en vez de forzar una integración semánticamente incorrecta para cumplir localidad. También deben distinguirse espera comercial, acceso a documentación y trabajo de ingeniería.

Límites del concepto

evolvability observa adaptación sostenida: un cambio sencillo hoy puede acumular excepciones que dificulten los siguientes. testability afecta el costo de obtener confianza; deployability afecta llevar el resultado a ejecución. Una frontera estable puede ayudar a las tres, con costos de abstracción y gestión.

Maintainability no se usa aquí como sinónimo automático. Los modelos de calidad pueden asignarle alcance diferente; la convención del Atlas evalúa costo y riesgo del cambio particular. La arquitectura se juzga contra escenario, entorno, respuesta y evidencia, conservando las diferencias entre atributos.