Software Architecture
Explica fitness functions como controles automatizados que verifican dependencias, contratos, seguridad, rendimiento y otras restricciones arquitectónicas en evolución.
Una fitness function convierte una intención arquitectónica en una comprobación objetiva. Su propósito no es medir todo, sino detectar temprano cuándo una característica importante se aleja del rango aceptable.
Las arquitecturas evolucionan con cada cambio. Aunque un diagrama inicial sea correcto, imports, configuraciones, datos y despliegues pueden degradar los límites de forma gradual.
Una fitness function responde:
característica importante
+ forma de medirla
+ umbral o regla
+ frecuencia
+ responsable
+ acción cuando fallaEjemplo:
característica: aislamiento entre módulos
medida: grafo de dependencias
regla: Orders no importa internals de Inventory
frecuencia: cada pull request
acción: bloquear merge y mostrar la ruta del importLa función no decide si los límites originales son buenos. Comprueba que el sistema sigue respetando una decisión explícita.
La documentación sola pierde autoridad cuando el código cambia.
Situaciones comunes:
Cada cambio parece pequeño. La degradación acumulada termina convirtiéndose en deuda difícil de revertir.
El gobierno automatizado acerca el feedback al momento donde el costo de corregir todavía es bajo.
El gobierno tradicional puede depender de aprobaciones centrales para cada decisión. Esto limita autonomía y crea colas.
El gobierno evolutivo define restricciones esenciales y permite libertad dentro de ellas.
principios y drivers
→ decisiones y límites
→ fitness functions
→ feedback continuo
→ aprendizaje
→ ajuste de reglasLas fitness functions son barandas. Impiden caer en riesgos conocidos, pero no prescriben cada detalle de implementación.
Ejemplo conceptual:
expect(dependencyGraph)
.not.toContainPath("domain", "infrastructure");Una implementación real puede usar análisis de imports o bytecode. El valor está en representar la regla del sistema, no en la herramienta.
Una regla útil distingue cambios compatibles e incompatibles. Bloquear cualquier diferencia generaría ruido y el equipo terminaría ignorándola.
tenant_id.Algunas reglas pueden verificarse estáticamente sobre schema; otras requieren queries y pruebas de migración.
Un benchmark inestable no debe bloquear cada commit. Puede ejecutarse periódicamente con tendencias y umbrales estadísticos.
Una herramienta que reporta una vulnerabilidad no determina automáticamente riesgo explotable. La política necesita severidad, exposición, excepciones y plazo de corrección.
No todas las funciones operativas pueden ejecutarse por commit. Algunas son simulacros periódicos.
Miden una sola propiedad: “no existen ciclos entre módulos”.
Evalúan varias partes de un escenario: “confirmar una venta conserva integridad y responde dentro del presupuesto bajo concurrencia”.
Analizan código, schemas o configuración sin ejecutar el sistema.
Necesitan ejecución: carga, seguridad, resiliencia o integración.
Se ejecutan con cada cambio o despliegue.
Backups, caos, capacity tests o revisiones de permisos pueden ejecutarse semanal o trimestralmente.
Algunas propiedades todavía requieren juicio humano. Una revisión estructurada puede ser una fitness function si posee criterio, evidencia y periodicidad; no es necesario automatizar de forma ficticia.
No midas algo solo porque la herramienta lo ofrece.
driver: cambios frecuentes en precios
riesgo: lógica dispersa en controladores
función: ninguna capa de transporte contiene reglas de pricingEl fallo debe indicar qué se rompió y dónde.
“Architecture score: 72” aporta poco. “OrdersController importa PrismaClient directamente” permite corregir.
Algunas reglas son binarias. Otras requieren rango.
Una prueba de imports puede correr en segundos. Un test de carga completo quizá deba ejecutarse por release.
Alguien debe mantener la regla, revisar excepciones y responder a fallos.
Una alerta sin acción es ruido.
Supón módulos sales, inventory, payments y notifications.
Reglas:
sales puede usar inventory.public
sales no puede importar inventory.internal
payments no escribe tablas de sales
notifications consume eventos, no tablas operacionalesUna fitness function analiza imports. Otra inspecciona permisos de base. Una tercera ejecuta contract tests de eventos.
La misma intención necesita varios mecanismos porque el límite existe en código, datos y comunicación.
Característica: ningún tenant puede observar recursos de otro.
Funciones:
tenant_id.Un solo check estático no demuestra aislamiento completo.
Una regla absoluta puede necesitar excepción legítima. Las excepciones deben ser:
excepción: Reporting lee réplica derivada de Sales
razón: consultas analíticas
límite: solo lectura, datos con retraso
revisión: al migrar pipeline analíticoDesactivar la regla global para resolver una excepción elimina su valor.
Cuando una medida se convierte en objetivo, las personas pueden optimizarla sin mejorar el sistema.
Ejemplos:
Combina métricas con el outcome que representan y revisa efectos secundarios.
Automatiza propiedades objetivas y frecuentes:
Conserva revisión para:
El objetivo no es reemplazar criterio, sino reservarlo para problemas que realmente lo necesitan.
Una fitness function también envejece.
Revisa cuando:
Versiona la política y registra por qué cambió. Relajar una regla puede ser correcto si existe nueva evidencia.
El equipo acumula dashboards sin conexión con decisiones importantes.
Si cada PR tarda horas o falla aleatoriamente, las personas buscarán evitarlos. Usa capas rápidas y suites profundas por release.
El fallo debe mostrar causa, impacto y forma de corrección.
Una convención estética no debería bloquear igual que una fuga entre tenants.
Herramientas, excepciones y umbrales necesitan ownership.
Un sistema puede respetar todas las reglas y tener boundaries equivocados. Las fitness functions protegen decisiones, no garantizan que sean correctas.
Para DomiSys, un conjunto inicial podría ser:
Evaluación y revisión de arquitectura enseña a combinar escenarios, evidencia y criterio humano para determinar si una arquitectura sigue siendo adecuada.