Fitness Functions
Feedback evaluable sobre una característica seleccionada
Una architectural Fitness Function proporciona evaluación objetiva de la integridad de alguna característica arquitectónica. Esa formulación de Ford, Parsons y Kua pone el foco en una expectativa específica y su evaluación, no en una prueba global de corrección. Building Evolutionary Architectures, primera edición, capítulo 2, 2017.
El término se toma de evolutionary computing, pero aquí se aplica a orientar arquitectura; no exige algoritmos genéticos ni una única función matemática. La pregunta práctica es qué característica importa, qué resultado refleja su conservación y qué evidencia permite evaluar un cambio.
«Debe ser mantenible» no basta como evaluación. Una dirección de dependencias permitida, compatibilidad entre versiones acordadas o latencia bajo una carga declarada permiten criterios más precisos. Objetivo significa que el criterio y su interpretación deben ser explícitos; no elimina juicio al elegirlo ni garantiza que represente toda la preocupación.
Expectativa, mecanismo y resultado
La característica no es la herramienta. Si Domain no debe depender de una implementación de Infrastructure, la intención es una restricción de dependencias. Un análisis estático o architecture test puede evaluar ciertas relaciones representadas. Instalar una herramienta sin declarar regla, alcance y limitaciones no demuestra esa relación de feedback.
Para performance, una expectativa puede usar p95 bajo workload W, entorno E y ventana acordada. Un load test o medición runtime aporta observación; hay que establecer población, unidad, condiciones y criterio de éxito. p95 sin explicar qué operaciones incluye puede ocultar precisamente el trabajo que importa.
Una Fitness Function vincula expectativa arquitectónica con evaluación. Puede producir pass/fail, una medida o un resultado que requiere revisión bajo criterios definidos. La respuesta organizacional es otra decisión: bloquear, investigar, aceptar temporalmente o revisar la expectativa no son el mismo mecanismo.
Diferencias y usos que pueden superponerse
| Elemento | Foco habitual | Relación con Fitness Functions |
|---|---|---|
| Unit test | Comportamiento de una unidad pequeña. | Puede aportar evaluación arquitectónica, pero no lo hace automáticamente. |
| Acceptance test | Comportamiento de negocio o sistema acordado. | Puede cubrir también una expectativa arquitectónica; las funciones no son categorías excluyentes. |
| Quality gate | Decisión de permitir un build o release según criterios. | Puede consumir resultados de Fitness Functions; evaluar y decidir paso son funciones distintas. |
| Monitoring y alert | Observación y señal ante una condición. | Pueden alimentar feedback arquitectónico si se relacionan con una expectativa explícita. |
| SLO | Objetivo de comportamiento del servicio. | Puede orientar una evaluación, pero el objetivo no es el mecanismo que lo contrasta. |
| Static-analysis rule | Comprobación sobre una representación estática. | Puede realizar una Fitness Function cuando evalúa una intención arquitectónica relevante. |
Un dashboard no se convierte automáticamente en Fitness Function por mostrar muchas métricas. A la inversa, un mismo test puede respaldar aceptación y un límite de performance. Clasificar por nombre de framework o tamaño del test pierde la pregunta sobre qué se está evaluando.
Automatización y momentos de evaluación
Automatizar puede reducir demora, variación y esfuerzo repetitivo, pero no define toda Fitness Function. El material de la primera edición incluye revisiones manuales de seguridad y auditoría dentro de su ejemplo de evaluación. Engineering Incremental Change, sample chapter.
Parsons y Ford también describen evaluaciones manuales junto a tests automatizados y explican el valor de un lenguaje común para comparar preocupaciones. Conversación sobre la segunda edición. Una revisión necesita criterio y evidencia; llamarla función no vuelve objetiva cualquier opinión.
La frecuencia depende de característica, costo y oportunidad de reacción: por commit, build, deployment, periódicamente, de forma continua o a demanda manual. Una regla de dependencias puede ejecutarse rápido; un ensayo representativo de recuperación puede requerir otro entorno y cadencia. CI-only dejaría fuera parte del comportamiento relevante.
No todas las restricciones pueden convertirse en checks automáticos fiables. Interpretación de contratos, trade-offs y cambios de contexto pueden requerir evaluación humana. Tampoco es necesario un único framework para reunir todos esos mecanismos.
La automatización también puede introducir accidental-complexity y costo de mantenimiento. Eso no la convierte automáticamente en deuda o erosión: revisar intención y carga futura conserva esas preguntas separadas.
Quality Attributes y escenarios
quality-attributes-overview organiza preocupaciones amplias. Una Fitness Function puede concretar una expectativa de performance, disponibilidad, seguridad o capacidad de cambio; no reduce una quality completa a su métrica elegida.
quality-attribute-scenarios ayuda a precisar estímulo, entorno, respuesta y medida. Supongamos que una carga acordada crea backlog y se amplía capacidad: evaluar que vuelva por debajo del umbral elegido dentro del plazo definido aporta evidencia para ese escenario. No demuestra toda Scalability ni todas las formas de scaling.
La evaluación debe incluir restricciones importantes. Si bajar backlog sacrifica órdenes válidas o traslada presión a una base, la medida aislada no respalda el resultado pretendido. Escenarios y compromisos complementarios ayudan a interpretar señales que pueden entrar en conflicto.
Commerce: cuatro evaluaciones diferentes
La intención de la variante propia es que Payments gobierne el estado autoritativo de pago y Orders use un contrato explícito. Inventory conserva reservas; Shipping requiere confirmación válida. La autorización pasa deliberadamente a un workflow diferido por análisis de fraude.
| Expectativa | Mecanismo posible | Qué evidencia aporta y qué no |
|---|---|---|
| Orders no depende de persistencia privada de Payments. | Análisis de dependencias sobre código y mapping acordado. | Detecta relaciones representadas; puede perder SQL dinámico o acceso indirecto. |
| La identidad de Orders no puede efectuar escrituras autoritativas de pago. | Revisión de privilegios y prueba controlada de denegación en el entorno pertinente. | Contrasta permisos efectivos examinados; no prueba todas las vías de modificación ni semántica de negocio. |
| Versiones soportadas de Orders y Payments coexisten. | Pruebas de contratos y combinaciones acordadas. | Aporta compatibilidad de lo ejercitado; no cubre automáticamente todos los datos y consumidores. |
| La autorización completa respeta el escenario de tiempo y disponibilidad. | Load test y evidencia runtime de resultados finales bajo condiciones declaradas. | Evalúa esa población y ventana; una respuesta de aceptación rápida no equivale a autorización terminada. |
Un permiso configurado es un control; su evaluación produce evidencia. Esta distinción evita llamar Fitness Function a cualquier mecanismo preventivo sin comprobar su efecto. La identidad utilizada en un test tampoco puede tener privilegios distintos de los relevantes sin declarar esa limitación.
En microservices, compatibilidad entre productor actual y consumidor anterior puede ser una combinación útil si pertenece a la política soportada. No se exige N/N-1 universalmente. deployment y deployability mantienen las preguntas sobre unidades, secuencias, datos y recuperación más allá de artifacts separados.
Guiar cambio y detectar desviaciones
evolutionary-architecture necesita orientación, feedback, interpretación y respuesta. Fitness Functions puede contribuir a ese ciclo, pero una colección de architecture tests no demuestra que exista una trayectoria guiada ni que se revisen decisiones cuando cambian drivers.
architecture-erosion examina debilitamiento de intención vigente. Una evaluación puede detectar ciertos desvíos, no todos. Si la arquitectura permite ahora A → B por una decisión justificada, una regla antigua que lo prohíbe necesita revisión. Conservar todos los checks sin considerar contexto puede impedir evolución legítima.
constraints hace explícitas obligaciones que algunas evaluaciones verifican. Conformance compara realización y restricciones o estructura pretendidas; también puede investigarse mediante revisión o reconstrucción. Ninguna técnica de conformance ni Fitness Function sustituye acordar qué intención está vigente.
technical-debt añade carga futura y legacy-systems contexto heredado. Puede haber deuda sin fallo en las funciones actuales, y un sistema legacy puede conservar sus expectativas. No corresponde inferir una etiqueta global a partir de un único resultado rojo o verde.
Cobertura, señales y confianza limitada
Una función puede fallar por ruido de entorno, datos no representativos o dependencias inestables. Flaky signals consumen atención y pueden terminar ignoradas; suprimirlas sin entender causa también puede eliminar una detección valiosa. Registrar condiciones y distinguir fallo del sistema de fallo del mecanismo mejora interpretación.
False positives pueden surgir de un mapping incorrecto o intención desactualizada. False negatives pueden dejar pasar caminos no modelados, datos distintos o cargas fuera de muestra. Pasar todas las funciones solo respalda expectativas y condiciones observadas; no prueba que no exista erosión, deuda o riesgo fuera de cobertura.
También puede optimizarse el indicador en lugar del resultado. En Commerce, excluir autorizaciones lentas de la población mejora el p95 mostrado sin acelerar la confirmación. El riesgo está en la definición y uso del proxy; no hace falta una puntuación universal ni sumar señales heterogéneas como si probaran calidad total.
testability facilita preparación, control y diagnóstico; operability aporta métricas, trazas y evidencia de ejecución. Datos observables sin contexto causal pueden resultar insuficientes, y producirlos también tiene costo. Un mecanismo muy caro puede retrasar feedback hasta hacerlo poco útil.
Elegir y mantener una evaluación útil
Durante strangler-fig, una evaluación puede contrastar resultados y asignación del trabajo; en parallel-change, combinaciones soportadas y condición de retiro; en branch-by-abstraction, dependencias y comportamiento de implementaciones. Las expectativas siguen siendo seleccionadas y parciales: el feedback no mueve tráfico, no reconcilia datos ni demuestra por sí solo que todos los consumidores migraron.
Comenzar por una característica importante para architectural-drivers, una degradación que interese detectar y evidencia que la refleje. Acordar criterio, alcance, frecuencia, responsable de interpretar resultados y reacción posible. No medir todo por disponibilidad de herramientas.
Las Fitness Functions evolucionan: versiones soportadas, workloads, límites y modelos pueden cambiar. Una revisión debe distinguir modificación legítima de criterio de ocultamiento de un fallo. Mantener trazabilidad del motivo permite evaluar si sigue protegiendo el compromiso relevante.
Como síntesis del Atlas: Evolutionary Architecture orienta cambio; Fitness Functions aporta feedback seleccionado; Architecture Erosion señala degradación respecto de intención. Juicio arquitectónico y otras evidencias deciden qué hacer. evolution-and-modernization conecta ese razonamiento sin convertir automatización, gates o métricas en una prueba de arquitectura globalmente correcta.