Fundamentos de Arquitectura

Para qué sirve este mapa

Este MOC abre el núcleo conceptual de Software Architecture. Permite pasar de preguntas sobre propósito y contexto a decisiones que condicionan el sistema. Los canónicos contienen las explicaciones; esta página organiza un recorrido y sus conexiones.

No exige completar una metodología antes de escribir código. Puede usarse para explorar un sistema nuevo, revisar un cambio o entender decisiones de una arquitectura existente. El punto de entrada depende de la pregunta que tenemos y de qué evidencia falta.

Como síntesis de navegación del Atlas, estos grupos ayudan a elegir una pregunta:

• Vocabulario: components, connectors, boundaries e interfaces.
• Configuración de unidades: decomposition, granularity y modularity.
• Razonamiento: architectural-drivers, constraints, essential-complexity, accidental-complexity y systems-thinking.
• Alcance avanzado: architectural-quantum [ADVANCED].

No son una taxonomía universal ni pasos obligatorios de un proceso.

Preguntas de entrada

Pregunta	Documento	Qué buscar
¿Qué es arquitectura de software?	software-architecture	Estructuras, decisiones, propiedades y razonamiento compartido.
¿Dónde termina Architecture y empieza Design?	architecture-vs-design	Alcance contextual, contratos y consecuencias del cambio.
¿Qué merece atención arquitectónica?	architectural-significance	Señales para distinguir importancia de influencia sistémica.
¿Qué fuerzas conducen las decisiones?	architectural-drivers	Objetivos, necesidades relevantes y restricciones.
¿Cómo evitar mejorar una parte perjudicando al conjunto?	systems-thinking	Interacciones, feedback, demoras y efectos de segundo orden.
¿Cómo establecer unidades y fronteras significativas?	decomposition	Responsabilidades, criterios de división y consecuencias.
¿Cuál es el menor alcance que sostiene independencia arquitectónica significativa?	architectural-quantum [ADVANCED]	Deployment, cohesión y coupling; precisar la formulación de los autores y el flujo evaluado.

Puede recorrerse la tabla en orden para una primera lectura. Durante una decisión real, conviene volver al documento que permita resolver la incertidumbre concreta, sin convertir la navegación en una secuencia obligatoria.

Elementos, interacción y límites

Concepto	Pregunta principal
constraints	¿Qué limita las alternativas posibles?
components	¿Qué elementos significativos realizan responsabilidades?
connectors	¿Cómo interactúan esos elementos?
boundaries	¿Dónde cambia una responsabilidad, autoridad o regla?
interfaces	¿Qué expone deliberadamente un elemento a otros?

Para revisar Commerce, identificar la condición impuesta al proveedor de pagos, las responsabilidades Orders y Payments, la autoridad sobre pagos, la capacidad pública de autorización y el mecanismo elegido para solicitarla. Los canónicos desarrollan estas diferencias con el mismo ejemplo; la tabla organiza la navegación sin duplicar sus definiciones.

Tamaño de unidades y calidad de sus límites

Concepto	Pregunta principal
decomposition	¿Qué unidades y fronteras establecemos?
granularity	¿Qué tan gruesas o finas son esas unidades para la vista considerada?
modularity	¿Cómo encapsulan responsabilidades y controlan dependencias e interacción?

Para comparar Payments como una unidad con Authorization, Capture, Refund y Settlement separados, usar Granularity. Para evaluar si Payments protege sus internals y ofrece contratos deliberados a Orders, usar Modularity. El mismo tamaño aparente puede conservar límites muy diferentes.

Components identifica elementos, Boundaries delimita reglas y Interfaces organiza lo expuesto. Estos fundamentos permiten analizar tamaño y encapsulación sin convertir un módulo lógico en servicio o deployment por defecto.

Origen y gestión de complejidad

Concepto	Pregunta principal
essential-complexity	¿Qué complejidad surge del problema y los resultados realmente requeridos?
accidental-complexity	¿Qué complejidad introducen representaciones, mecanismos y decisiones de solución?

La frontera depende del problema, los drivers y las restricciones considerados; no clasifica objetivamente cada línea de código ni identifica categorías morales. En Commerce, distinguir captura de autorización puede ser necesario, mientras duplicar representaciones internas agrega trabajo que requiere otra justificación.

Constraints restringe el espacio disponible; Decomposition establece unidades; Granularity compara su alcance; Modularity examina encapsulación y relaciones. El par Essential/Accidental permite revisar de dónde viene la dificultad y si la intervención elimina, oculta, traslada o automatiza trabajo. Estas preguntas se complementan y pueden revisarse en cualquier orden.

Un recorrido iterativo

Context
→ Drivers
→ Architecturally significant concerns
→ Architecture decisions
→ System structures / constraints
→ Consequences
→ Feedback / evolution
→ revised context, drivers and decisions

El contexto identifica propósito, participantes, entorno y sistema considerado. Los drivers seleccionan influencias relevantes; las preocupaciones significativas permiten delimitar qué compromisos merecen análisis. Las decisiones materializan respuestas y alternativas descartadas.

Las estructuras y restricciones resultantes permiten observar consecuencias. El feedback revisa hipótesis, revela necesidades y cambia prioridades. El modelo admite saltos y retornos: un prototipo puede descubrir una restricción, y un problema de integración puede mostrar que entendimos mal el contexto.

No representa waterfall. Tampoco propone diseñar toda la arquitectura de antemano. El análisis debe acompañar el costo, alcance e incertidumbre de la decisión actual.

Recorridos según la necesidad

Entender una arquitectura existente: comenzar con software-architecture, preguntar qué estructuras permiten razonar sobre sus compromisos y usar architectural-drivers para recuperar sus motivos. Contrastar intención con operación, contratos y datos reales.

Revisar un cambio pequeño: comenzar con architecture-vs-design y architectural-significance. Un cambio breve puede alterar expectativas externas; uno voluminoso puede preservar todos los compromisos. Buscar consecuencias antes de decidir cuánto tratamiento necesita.

Elegir una alternativa: comenzar con architectural-drivers y systems-thinking. Aclarar resultados, restricciones y costos desplazados. Comparar consecuencias en escenarios relevantes, incluyendo efectos posteriores y dependencias entre participantes.

Vocabulario, dimensiones y perfiles

Foundations aporta vocabulario para describir elementos, límites, interfaces y restricciones. architecture-decision-axes organiza preguntas analíticas: decomposition, communication, deployment y scaling permiten examinar decisiones con esos elementos. architecture-profile reúne paquetes de respuestas, como modular-monolith y microservices, sin reducir un perfil al número de componentes o fronteras.

Son papeles complementarios, no una secuencia obligatoria. Puede comenzarse por una interacción problemática, recuperar la responsabilidad y su límite, revisar el eje relevante y contrastar variantes de un perfil. event-driven-architecture aplica estas preguntas a interacción y reacción mediante hechos.

Puentes con conocimiento existente

• dual-write-problem y transactional-outbox ilustran cómo una promesa de negocio condiciona fronteras de confirmación y recuperación, más allá de elegir tecnologías.
• blast-radius y bulkhead permiten comparar consecuencias de compartir o separar recursos. Son ejemplos de significancia y trade-offs, no una definición general de arquitectura.
• retry, overload y retry-storms muestran cómo una reacción local puede agravar el resultado global.
• metastable-failures y queue-management ayudan a pensar persistencia, demoras y horizonte de recuperación.

Estas conexiones aprovechan canónicos existentes. Los fundamentos no redefinen sus mecanismos ni hacen de Reliability un prerrequisito para toda conversación arquitectónica.

Alcance actual y continuación

La cobertura incorpora granularity y modularity al vocabulario de elementos, interacción y límites. decomposition participa también como Decision Axis mediante el mismo canonical, sin duplicar definición por su presencia en dos ramas del Knowledge Map. essential-complexity y accidental-complexity permiten razonar sobre origen y gestión de dificultad bajo requisitos y restricciones explícitos. architectural-quantum completa el alcance [ADVANCED], con procedencia autoral y evolución terminológica explícitas.

Architecture Foundations V0.3 está materialmente completo: cada concepto previsto tiene un canonical y ubicación resuelta. Esto describe cobertura editorial; los documentos mantienen su estado draft y requieren revisión personal.

quality-attributes, architecture-decision-axes y architecture-profiles desarrollan recorridos relacionados: resultados evaluables, dimensiones de decisión y paquetes arquitectónicos. Architecture Practice continúa pendiente. La navegación no exige completar todos los recorridos antes de decidir.

Para revisar una decisión ahora, alcanza con preguntar qué necesidad la justifica, a quién afecta, qué compromisos introduce, qué evidencia falta y cuándo reconsiderarla. El recorrido conserva esas preguntas abiertas mientras cambia nuestro entendimiento del sistema.

Para continuar hacia terminología y soluciones reutilizables, architecture-patterns organiza estilos, patrones y perfiles. architecture-pattern-terminology compara los usos entre autores y aclara la convención editorial del Atlas antes de leer arquitecturas nombradas.