Software Architecture
Qué es
Software Architecture permite razonar sobre las estructuras y decisiones significativas de un sistema de software. Bass, Clements y Kazman, en Software Architecture in Practice, la caracterizan mediante las estructuras necesarias para razonar sobre el sistema: elementos, relaciones y propiedades de ambos. Esta formulación aparece en la presentación del SEI Architecture-Centric Procurement, p. 4.
ISO/IEC/IEEE 42010:2011 sitúa la arquitectura en los conceptos o propiedades fundamentales de un sistema en su entorno, materializados en elementos, relaciones y principios de diseño y evolución. Su modelo conceptual público distingue arquitectura de descripción de arquitectura. Un sistema puede tener arquitectura aunque nadie la haya documentado; un documento expresa una interpretación de ella, no constituye por sí solo el sistema.
Ambas perspectivas ayudan a preguntar qué organización permite cumplir el propósito del sistema y bajo qué supuestos. «Significativo» depende del contexto: una decisión sobre datos, aislamiento o contratos puede condicionar muchas capacidades, aunque ocupe pocas líneas de código. architectural-significance desarrolla ese criterio; architecture-vs-design explica su continuidad con el diseño cotidiano.
Estructuras para razonar
No existe necesariamente un único dibujo que contenga toda la arquitectura. Una representación puede mostrar unidades de código y dependencias; otra, procesos e interacciones durante ejecución; otra, asignación a entornos de despliegue. Aquí, «elemento» significa la unidad relevante para esa pregunta, no necesariamente un servicio desplegable. components desarrolla cómo representar responsabilidades y estado según la vista, sin equiparar component con clase o container.
Las relaciones también necesitan significado. Una flecha puede representar invocación, dependencia de compilación, transferencia de datos o control administrativo. Si no se identifica cuál, resulta difícil deducir consecuencias. Que dos cajas se comuniquen no revela quién espera a quién, quién conserva estado ni qué ocurre si se pierde una respuesta. connectors permite describir mecanismos de interacción y su semántica; no toda relación de compilación o control administrativo es un connector de runtime.
Las propiedades relevantes incluyen contratos, capacidad esperada, reglas de acceso, responsabilidad sobre datos y comportamiento frente a fallos. La descripción selecciona aquellas que permiten evaluar una preocupación concreta; no necesita copiar cada detalle de implementación. La arquitectura debe ser suficientemente precisa para confrontar hipótesis con el sistema construido.
Tres perspectivas complementarias
- Estructura: qué partes existen, cómo se relacionan y qué propiedades condicionan su comportamiento. Permite seguir caminos de ejecución, datos, cambios y dependencias.
- Decisiones: por qué se eligió esa organización, qué alternativas se descartaron y qué consecuencias se aceptaron. Jansen y Bosch proponen representar explícitamente las decisiones arquitectónicas para evitar perder el conocimiento que las estructuras dejan implícito. Software Architecture as a Set of Architectural Design Decisions, 2005.
- Modelo y razonamiento compartido: cómo diferentes participantes entienden el sistema y comprueban sus compromisos. Un equipo puede asumir entrega inmediata mientras otro presupone procesamiento posterior; hacer visible esa diferencia evita construir contratos incompatibles.
Estas perspectivas se complementan. Las decisiones producen estructuras; las estructuras permiten ciertas propiedades y limitan otras; el razonamiento explicita si esas consecuencias satisfacen las necesidades. Registrar una intención sin verificar su realización deja una arquitectura aspiracional. Mostrar estructuras sin sus motivos dificulta decidir cómo evolucionarlas.
Arquitectura y tecnología
Arquitectura no equivale a seleccionar tecnologías. Enumerar .NET, PostgreSQL, Azure y Kafka informa sobre implementaciones, pero no explica responsabilidades, límites de autoridad, interacción, restricciones ni consecuencias de fallo.
Una descripción útil responde por qué existe cada parte, dónde ejecuta, quién posee los datos, qué contratos expone, qué dependencia necesita para cumplirlos y cómo cambia el conjunto. También explica qué resultados se consideran aceptables durante degradación y qué compromisos deberán revisarse si crece el negocio.
Las tecnologías importan porque habilitan o restringen decisiones: una plataforma puede imponer un modelo de despliegue o un servicio puede limitar residencia de datos. Su elección necesita conectarse con architectural-drivers, no convertirse en sustituto del razonamiento.
Ejemplo: publicación de pedidos
Dos diseños pueden usar la misma base de datos, broker y lenguaje, y tener arquitecturas diferentes. En uno, la aplicación guarda un pedido y publica una notificación como acciones independientes. En otro, conserva el pedido y la intención de publicación dentro de una transacción local; un proceso posterior entrega esa intención.
La diferencia relevante no es el número de cajas. Cambian las fronteras de confirmación, la responsabilidad de recuperación y el significado de una respuesta al cliente. dual-write-problem explica la ventana del primer diseño; transactional-outbox desarrolla una alternativa para el segundo.
El segundo diseño no mejora automáticamente todas las propiedades. Puede reducir publicaciones perdidas, pero introduce propagación posterior, seguimiento de pendientes y posibles repeticiones. El negocio debe decidir cuánto retraso tolera y qué efectos requieren protección. Elegirlo sin esas condiciones sería adoptar una solución técnica antes de entender el problema.
Qualities, constraints y trade-offs
El SEI presenta la arquitectura como soporte para analizar cualidades esenciales antes de que implementación e integración hagan costoso descubrir riesgos. Software Architecture. Disponibilidad, seguridad, modificabilidad y rendimiento requieren interpretar quality-attribute-scenarios, no adjetivos como «robusto» o «escalable». quality-attributes-overview organiza esa relación con funcionalidad y contexto.
Las restricciones delimitan alternativas: contratos existentes, regulación, presupuesto o capacidades operativas pueden impedir una opción técnicamente atractiva. Deben identificarse para distinguir una elección voluntaria de una obligación externa.
Los trade-offs son normales. Esperar una confirmación durable puede aumentar latencia; reservar recursos para aislar cargas reduce eficiencia de uso; incorporar extensiones futuras puede aumentar complejidad actual. En ciertos escenarios de partición, disponibilidad de operaciones y garantías de consistencia también entran en tensión. Ninguna de estas relaciones justifica reglas universales sin declarar escenario y garantía. quality-attribute-trade-offs compara efectos esperados, consecuencias secundarias y evidencia, incluyendo feedback sobre los supuestos.
Cambio, entorno y participantes
Las decisiones arquitectónicas condicionan el cambio futuro. Acoplamiento, contratos compartidos, datos persistentes, límites de despliegue y consumidores externos pueden exigir migraciones coordinadas. El costo no está únicamente en editar código: incluye coexistencia, comunicación, validación y recuperación.
evolution-and-modernization organiza esa perspectiva temporal. technical-debt identifica condiciones que agregan carga futura; legacy-systems examina valor y restricciones de sistemas heredados. Ninguna etiqueta determina por sí sola que deba reescribirse o reemplazarse la solución.
«Difícil de cambiar» es una señal, no una definición completa. Un error accidental puede ser costoso de corregir sin representar una decisión arquitectónica; una frontera bien diseñada puede ser significativa precisamente porque facilita cambios baratos.
Usuarios, operación, desarrollo, seguridad y negocio tienen preocupaciones distintas. La arquitectura necesita relacionarlas con evidencia y hacer visibles desacuerdos. systems-thinking amplía esa mirada a incentivos, interacciones y efectos posteriores.
system-design-practice organiza la síntesis aplicada: requirements-to-architecture interpreta necesidades e influencias significativas; design-process desarrolla y evalúa decisiones candidatas. Un diagrama o una lista de tecnologías no sustituye explicar qué compromisos realiza la propuesta ni qué evidencia permitiría revisarla.
Revisar arquitectura consiste en contrastar decisiones y supuestos con necesidades actuales y evolución probable. Diagramas, modelos y registros ayudan cuando permiten explicar consecuencias comprobables. El recorrido architecture-foundations conecta estas preguntas sin exigir una documentación exhaustiva antes de comenzar a construir. architectural-style y architectural-pattern explican formas de reutilizar organización y razonamiento; architecture-pattern-terminology ayuda a interpretar sus nombres sin imponer categorías universales. architecture-profiles compara decisiones de deployment, datos, autonomía y operación de arquitecturas nombradas.