Software Architecture
Explica cómo identificar y priorizar objetivos, funcionalidad crítica, atributos de calidad, restricciones y riesgos que justifican decisiones arquitectónicas.
Los drivers arquitectónicos son las fuerzas concretas que justifican una decisión estructural. Sin drivers priorizados, la arquitectura se convierte en una colección de gustos técnicos imposibles de evaluar.
Antes de elegir módulos, bases de datos, estilos de integración o topologías de despliegue, necesitas comprender qué debe proteger el sistema y bajo qué restricciones debe hacerlo.
Los drivers arquitectónicos conectan el problema con la estructura:
objetivos de negocio
+ comportamiento crítico
+ atributos de calidad
+ restricciones
+ riesgos
↓
alternativas arquitectónicas
↓
trade-offs y decisión
↓
evidencia de que funcionaUn driver no es una palabra como “escalabilidad” ni una preferencia como “usar microservicios”. Debe expresar una necesidad significativa, su contexto y el impacto de no cumplirla.
Muchos equipos comienzan el diseño preguntando:
Estas preguntas empiezan por la solución. Sin contexto, varias respuestas pueden parecer correctas y ninguna puede justificarse.
Los drivers cambian la conversación:
“¿Microservicios?”
↓
“¿Qué capacidad necesita desplegarse de forma independiente,
por qué, con qué frecuencia y qué equipo la operará?”Al convertir deseos vagos en condiciones observables, los drivers permiten comparar alternativas y detectar complejidad innecesaria.
Explican qué resultado pretende alcanzar o proteger la organización.
Ejemplos:
El objetivo por sí solo no determina la arquitectura, pero da sentido a las prioridades. “Entrar en tres países” puede implicar idiomas, monedas, latencia regional, impuestos y residencia de datos; cada una necesita análisis adicional.
No toda funcionalidad afecta la estructura global. Una feature se vuelve arquitectónicamente significativa cuando introduce alguno de estos factores:
En DomiSys, cambiar el color de una tarjeta no es arquitectónicamente significativo. Reservar inventario durante pedidos simultáneos sí lo es porque exige definir ownership, consistencia, transacciones y comportamiento ante fallos.
Describen cómo debe comportarse el sistema, no qué función completa.
Algunos ejemplos:
No deben permanecer como etiquetas. “Debe ser rápido” no permite diseñar ni validar nada. Un atributo útil se convierte en escenario medible, como se desarrolla en la siguiente nota.
Son condiciones que limitan las alternativas.
Pueden ser:
Una restricción no siempre es permanente. Debe indicarse si es fija, negociable o asumida temporalmente.
Una decisión puede necesitar prioridad no porque ya exista un requisito, sino porque el costo de equivocarse es alto.
Ejemplos:
La respuesta correcta puede ser una prueba de concepto, un experimento o instrumentación, no una arquitectura más compleja.
Considera esta frase:
“El sistema debe escalar.”No aclara:
Una formulación más útil sería:
Durante campañas de fin de semana,
el catálogo debe soportar 800 lecturas por segundo
con p95 menor a 300 ms,
mientras la escritura de pedidos permanece por debajo de 80 solicitudes por segundo.Esta versión sugiere alternativas concretas: caching para catálogo, índices adecuados, pools dimensionados y aislamiento de recursos. No obliga automáticamente a distribuir toda la aplicación.
Pregunta qué valor se espera y qué fracaso sería inaceptable.
No basta con “crear una plataforma de pedidos”. Debes conocer si la prioridad es evitar pedidos perdidos, controlar inventario, reducir atención por WhatsApp o habilitar múltiples negocios.
Busca operaciones con dinero, datos sensibles, concurrencia, integración, alto volumen o impacto operativo.
Convierte palabras abstractas en escenarios con carga, entorno y medida.
Separa hechos de preferencias y supuestos.
hecho: el proveedor solo admite 100 solicitudes/s
preferencia: el equipo prefiere TypeScript
supuesto: ningún tenant superará 50.000 productosCada categoría exige tratamiento diferente. Un supuesto necesita validación; una preferencia puede ceder ante un driver más importante.
Los drivers compiten. La priorización obliga a indicar qué se protege primero.
Solo después se comparan alternativas y sus consecuencias.
Todo driver importante necesita prueba, métrica o revisión que permita saber si se cumple.
No todos los drivers pueden recibir prioridad máxima. Utiliza criterios como:
Una matriz sencilla puede separar:
alta importancia + alta incertidumbre
→ investigar primero
alta importancia + baja incertidumbre
→ diseñar y verificar
baja importancia + alta complejidad
→ evitar sobrearquitecturaUna reserva de inventario puede preferir rechazar temporalmente una operación antes que confirmar stock inexistente. Un catálogo público puede servir datos ligeramente antiguos para permanecer disponible.
Un monolito modular puede acelerar entrega con un equipo pequeño. Microservicios podrían aportar independencia futura, pero exigen pipelines, observabilidad, contratos y soporte que retrasan el lanzamiento.
Autenticación adicional, separación de funciones y auditoría aumentan control, pero también pasos y costo de implementación. El nivel adecuado depende del activo y la amenaza.
Una interfaz y un adapter pueden proteger una frontera externa. Crear esas abstracciones para funciones estables y triviales solo aumenta navegación.
Supón estos objetivos:
De ellos pueden derivarse drivers:
Un negocio no puede leer ni modificar datos de otro, incluso si conoce sus IDs. Esto afecta identidad, queries, cachés, archivos, eventos y jobs.
Dos pedidos concurrentes no pueden reservar la misma última unidad. Esto favorece mecanismos transaccionales y constraints cerca del dato.
El equipo no tiene una plataforma dedicada ni on-call para decenas de servicios. Esto favorece menos unidades de despliegue y observabilidad centralizada.
Los límites todavía están aprendiendo. Extraer servicios demasiado pronto podría congelar modelos incorrectos.
La experiencia del cliente necesita payloads controlados, caché pública y frontend eficiente, pero esto no obliga a separar todos los módulos backend.
A partir de esos drivers:
alternativa A: microservicios desde el inicio
+ independencia potencial
- alta carga operativa
- contratos prematuros
- consistencia distribuida
alternativa B: monolito sin límites
+ implementación inicial rápida
- ownership difuso
- extracción futura difícil
alternativa C: monolito modular
+ transacciones locales
+ menor operación
+ límites explícitos
- despliegue conjunto
- necesita enforcement internoLa alternativa C puede ser la mejor hipótesis inicial. No porque el monolito sea universalmente superior, sino porque se ajusta mejor a los drivers actuales.
Una auditoría útil distingue:
No puede cambiarse fácilmente: regulación, contrato, protocolo legado.
Puede cambiar, pero necesita inversión: experiencia del equipo, proceso de despliegue, ownership.
Se acepta sin evidencia: “siempre tendremos conexión estable”. Debe registrarse y validarse.
Surge de una decisión anterior: usar un proveedor que limita regiones. Debe poder cuestionarse.
Tratar todas como permanentes reduce innecesariamente el espacio de solución.
Métricas de adopción, tiempo de operación, costo, errores o cumplimiento.
Pruebas de carga, histogramas y medición bajo tráfico real.
Threat modeling, pruebas de autorización, auditoría y revisión de incidentes.
Tiempo y alcance de cambios reales, dependencias y despliegues coordinados.
SLO, recuperación, incidentes y simulacros.
Experimentos, spikes, pruebas de concepto o telemetría temporal.
“Necesitamos Kafka” no es un driver. Investiga si el problema es fan-out, desacoplamiento temporal, replay o throughput. Quizá una outbox y una cola sencilla sean suficientes.
“Seguro”, “rápido” y “escalable” permiten interpretaciones incompatibles. Añade contexto y medida.
Si disponibilidad, consistencia, costo, velocidad y flexibilidad son prioridad máxima, no existe guía para decidir. Explicita qué cede cuando entran en conflicto.
Una arquitectura operable por otra empresa puede ser inviable para tu organización. La capacidad humana es parte del sistema.
Sobreestimar carga introduce distribución y costo antes de tener evidencia. Conserva opciones, pero dimensiona con datos y márgenes razonables.
Los objetivos y restricciones cambian. Una decisión correcta puede volverse deuda cuando desaparece el driver que la justificaba.
Producto puede priorizar velocidad; operaciones, estabilidad; legal, cumplimiento. La arquitectura no resuelve el conflicto en secreto. Debe hacerlo visible y requerir una decisión de negocio.
Trabaja con rangos, supuestos explícitos y pruebas. No presentes una estimación como certeza.
Investiga su origen. Puede ocultar regulación, incidente previo o dependencia contractual. Si ya no aplica, registra su eliminación.
Revisa ADRs, riesgos y alcance. No continúes por costo hundido sin reevaluar consecuencias.
En una herramienta interna pequeña puede bastar con:
En pagos, salud, plataformas multi-tenant o sistemas distribuidos, la profundidad debe aumentar porque equivocarse es más costoso.
Atributos de calidad profundiza en las propiedades que convierten los objetivos en comportamiento observable y que generan los principales trade-offs arquitectónicos.