Funciones de aptitud y arquitectura evolutiva

De la evaluación puntual a la comprobación continua

Una evaluación como el ATAM (Sección 11.1) es una instantánea. Al día siguiente de terminar, los desarrolladores empiezan a cambiar el sistema, y cada cambio puede deshacer en silencio una decisión en la que se apoyaba la evaluación: una importación cómoda a través del límite de un módulo, una llamada síncrona adicional en la ruta del pedido, una biblioteca con una vulnerabilidad conocida. La Sección 1.7 describió el resultado: la erosión, cuando se viola la arquitectura, y la deriva, cuando se ignora. Las revisiones periódicas detectan parte de esto, con meses de retraso. La idea de esta sección es comprobar las decisiones arquitectónicas más importantes de forma automática y continua, del mismo modo que las pruebas unitarias comprueban el comportamiento.

El término procede del libro de Neal Ford, Rebecca Parsons y Patrick Kua Building Evolutionary Architectures (O'Reilly, 2017), cuya segunda edición, con Pramod Sadalage, apareció en noviembre de 2022. Lo tomaron de la computación evolutiva, donde una función de aptitud puntúa lo cerca que está una solución candidata del objetivo para que el algoritmo pueda quedarse con las mejores variantes. En arquitectura, el objetivo es el conjunto de características que el sistema debe conservar mientras todo lo demás cambia.

Qué es una función de aptitud

La segunda edición define una función de aptitud (fitness function) arquitectónica como cualquier mecanismo que proporciona una evaluación objetiva de la integridad de alguna característica o características de la arquitectura. Tres expresiones de esa definición hacen el trabajo. Cualquier mecanismo: una prueba unitaria, una regla de análisis estático, una prueba de carga, un monitor, un experimento de caos o incluso una revisión manual programada cumplen los requisitos. Objetiva: el resultado no debe depender de quién la ejecute; "el código parece bien estructurado" no es una función de aptitud, "ningún paquete de la capa de dominio importa el framework web" sí lo es. Característica de la arquitectura: la comprobación protege una cualidad que la arquitectura existe para ofrecer (rendimiento, disponibilidad, modificabilidad, seguridad, compatibilidad de datos), no una regla de negocio, que es tarea de las pruebas ordinarias.

En la práctica, una función de aptitud útil tiene algunas propiedades más. Está vinculada a un requisito, idealmente un escenario de atributo de calidad cuya medida de la respuesta se convierte en su umbral (Sección 2.3). Tiene un responsable que decide qué ocurre cuando falla. Falla de forma ruidosa, rompiendo una compilación o avisando a alguien de guardia, en lugar de alimentar un panel que nadie lee. Y su umbral y el motivo de este quedan registrados, normalmente en un ADR, para que un equipo posterior pueda distinguir entre una regla que protege algo importante y un número arbitrario.

La Sección 3.8 trazó la distinción importante con las métricas: una métrica describe, una función de aptitud decide. Una métrica de acoplamiento en un panel te dice que las cosas empeoran; una función de aptitud codifica una decisión que el equipo ya ha tomado, de modo que incumplirla obliga a una elección consciente: corregir el código, o cambiar la regla y registrar por qué.

Categorías de funciones de aptitud

Ford y sus coautores clasifican las funciones de aptitud según varias dimensiones independientes. La clasificación es útil menos como taxonomía que como estímulo para el diseño: preguntarse "¿debería ser atómica u holística, activada o continua?" a menudo revela una comprobación mejor que la primera que vino a la mente.

Las comprobaciones holísticas merecen atención porque las cualidades interactúan: los controles de seguridad añaden latencia, la caché complica la frescura de los datos, y una prueba atómica de cada una por separado puede pasar mientras la combinación falla. Las comprobaciones continuas importan porque algunas características solo existen en producción: la latencia real de los usuarios, los modos de fallo reales, el costo real. Una cartera sana combina comprobaciones rápidas, atómicas y activadas en la compilación con un número menor de comprobaciones holísticas más lentas antes del lanzamiento y comprobaciones continuas en producción.

Funciones de aptitud para cada cualidad

La mayoría de los equipos empiezan por la estructura, porque las comprobaciones estructurales son baratas, rápidas y deterministas, y después añaden comprobaciones de rendimiento, seguridad, resiliencia y datos a medida que madura el pipeline. La tabla ofrece ejemplos típicos; las herramientas cambian, los patrones no.

La arquitectura evolutiva y el cambio incremental

Las funciones de aptitud son una mitad de lo que Ford, Parsons, Kua y Sadalage llaman arquitectura evolutiva: una arquitectura que admite un cambio guiado e incremental en múltiples dimensiones. Cada parte de la frase es un requisito de diseño.

El cambio incremental tiene una vertiente de desarrollo y otra operativa. Los desarrolladores deben poder hacer cambios pequeños con seguridad, lo que depende de la modularidad y de un acoplamiento adecuado (Capítulo 3) y de mantener cada parte desplegable de forma independiente, el cuanto de arquitectura de la Sección 5.1, lo bastante pequeña para cambiarla sin coordinarse con otros. Las operaciones deben poder lanzar cambios pequeños con frecuencia y con seguridad, lo que depende de un pipeline de despliegue, un despliegue progresivo y un rollback rápido (Sección 10.5). Guiado es donde entran las funciones de aptitud: definen qué significa "apto" e impiden que los incrementos lo degraden. Múltiples dimensiones recuerda que la arquitectura no es solo la estructura del código: los datos, la seguridad, las operaciones, la estructura de los equipos y el costo evolucionan, y todos necesitan protección.

El enfoque cambia la forma en que los arquitectos piensan en el futuro. En lugar de predecir cada requisito y construir de antemano flexibilidad para él, algo que la Sección 3.8 mostró que es caro y a menudo erróneo, el equipo mantiene el sistema fácil de cambiar y protege solo las características que importan, aplazando las demás decisiones hasta el último momento responsable (Sección 1.6). Los críticos señalan límites reales. No todas las cualidades se pueden comprobar de forma automática o barata; los umbrales mal elegidos generan ruido que los equipos aprenden a ignorar; y algunas decisiones, como una base de datos o un proveedor de nube, siguen siendo puertas de un solo sentido por bueno que sea el pipeline. La arquitectura evolutiva es una disciplina para mantener reversibles las partes reversibles y protegidas las partes importantes, no una promesa de que todo se podrá cambiar más adelante.

import http from 'k6/http';
import { check } from 'k6';

export const options = {
  scenarios: {
    friday_peak: { executor: 'constant-arrival-rate', rate: 100, timeUnit: '1s',
                   duration: '10m', preAllocatedVUs: 300 },   // 100 orders per second
  },
  thresholds: {   // the scenario's response measure, as pass/fail rules
    'http_req_duration{name:place_order}': ['p(95)<1500', 'p(99)<3000'],
    'http_req_failed{name:place_order}': ['rate<0.001'],
  },
};

const order = { restaurantId: 'r-42', items: [{ sku: 'pad-thai', qty: 1 }] };

export default function () {
  const res = http.post(`${__ENV.BASE_URL}/orders`, JSON.stringify(order), {
    headers: { 'Content-Type': 'application/json' }, tags: { name: 'place_order' } });
  check(res, { 'order accepted': (r) => r.status === 201 || r.status === 202 });
}

# Fitness function: checkout keeps accepting orders when payments hang (illustrative)
# Runs weekly in staging; toxiproxy, api and ledger are test fixtures.
def test_orders_survive_payment_provider_outage(toxiproxy, api, ledger):
    toxiproxy.add_latency("payment-provider", latency_ms=30_000)   # provider hangs
    placed = [api.place_order(sample_order()) for _ in range(200)]

    assert all(r.status in (201, 202) for r in placed)            # still accepted
    assert all(r.json()["state"] == "PENDING_PAYMENT" for r in placed)
    assert max(r.elapsed_seconds for r in placed) < 10            # told within 10 s

    toxiproxy.remove_toxics("payment-provider")                    # provider recovers
    ledger.wait_until_settled(timeout_seconds=300)
    assert ledger.lost_orders(placed) == []                        # none lost

# .importlinter: only the POS adapters may use vendor SDKs
[importlinter]
root_package = fooddelivery
include_external_packages = True

[importlinter:contract:pos-vendors-isolated]
name = Vendor POS SDKs are used only inside the POS adapters
type = forbidden
source_modules =
    fooddelivery.restaurant.domain
    fooddelivery.restaurant.api
    fooddelivery.ordering
forbidden_modules =
    tillpro_sdk
    kitchenlink

[importlinter:contract:adapters-independent]
name = POS adapters do not import each other
type = independence
modules =
    fooddelivery.restaurant.pos_adapters.tillpro
    fooddelivery.restaurant.pos_adapters.kitchenlink

La compatibilidad de los datos se protege de la misma manera. Antes de que pueda fusionarse un cambio en el evento OrderPlaced, el pipeline pregunta al registro de esquemas si el nuevo esquema es compatible con la última versión registrada según la regla de compatibilidad del sujeto, y falla si no lo es:

# Data fitness function: block the merge if the new event schema would break consumers
curl -s -X POST -H "Content-Type: application/vnd.schemaregistry.v1+json" \
  --data @build/order-placed-v7.request.json \
  "$SCHEMA_REGISTRY_URL/compatibility/subjects/order-placed-value/versions/latest" \
  | jq -e '.is_compatible == true'

Diseñar funciones de aptitud que perduren

Empieza por poco y por lo importante. Elige las tres a cinco características que el árbol de utilidad valora más alto, escribe una función de aptitud para cada una y asegúrate de que sean rápidas y fiables antes de añadir más. Una docena de comprobaciones de confianza valen más que cien que fallan al azar.

Usa trinquetes (ratchets) en los sistemas existentes. Cuando una base de código ya viola una regla, registra las violaciones actuales como línea base y falla solo ante las nuevas; endurece la línea base a medida que el equipo salda la deuda. Lo mismo sirve para el rendimiento: falla ante regresiones superiores a un margen acordado respecto al último lanzamiento mientras avanzas hacia el objetivo del escenario.

Haz que los umbrales sean explícitos y tengan responsable. Guarda los umbrales en una configuración bajo control de versiones junto a una referencia al ADR que los justifica, con un responsable con nombre. Cuando una función de aptitud falla, el responsable decide entre corregir el código y cambiar la regla, y la decisión se registra. Trata una función de aptitud que se anula con frecuencia como un hallazgo: o la regla está mal o la arquitectura está sometida a una presión real.

Mantén el pipeline rápido. Las comprobaciones atómicas van en cada compilación; las comprobaciones holísticas pesadas, como las pruebas de carga de diez minutos, se ejecutan cada noche, antes del lanzamiento o sobre la versión candidata. Las comprobaciones continuas en producción necesitan el mismo cuidado que cualquier alerta: vinculadas al impacto en los usuarios, con un runbook y en silencio cuando no pasa nada.