Patrones de Arquitectura

Para qué sirve este mapa

Este MOC conecta la terminología necesaria para interpretar y comparar aproximaciones de arquitectura y diseño. El objetivo es entender qué problema, alcance y decisiones hay detrás de un nombre antes de incorporarlo al diseño o al Knowledge Graph.

Si dos libros parecen contradecirse porque uno dice style y otro pattern, comenzar por la disambiguación. Si la duda es sobre aplicabilidad o consecuencias, continuar hacia el canonical correspondiente.

Preguntas de entrada

Pregunta	Documento	Foco de lectura
¿Qué significa Architectural Style?	architectural-style	Vocabulario y restricciones de organización.
¿Qué significa Architectural Pattern?	architectural-pattern	Problema, contexto, fuerzas, solución y consecuencias.
¿Por qué el Atlas usa Architecture Profiles?	architecture-profile	Paquetes de decisiones sobre múltiples ejes.
¿Architectural Style y Architecture Profile son categorías equivalentes?	architectural-style-vs-architecture-profile	Término de las fuentes y representación del Atlas; no categorías universales en competencia.
¿Qué es un Design Pattern?	design-pattern	Intención, participantes y colaboraciones de diseño.
¿Por qué la terminología parece contradictoria?	architecture-pattern-terminology	Variación entre autores y convención editorial del Atlas.

La tabla ofrece entradas, no una escalera de tamaños ni categorías universales. Los documentos conceptuales contienen definiciones y ejemplos; este mapa conserva preguntas y recorridos.

Recorrido para leer una fuente

Comenzar con architecture-pattern-terminology para identificar el marco del autor. Después usar architectural-style si la descripción destaca reglas de organización, o architectural-pattern si desarrolla una solución y las fuerzas que la justifican.

Si la fuente trata colaboraciones internas, continuar con design-pattern y preguntar qué contexto hace útil esa solución. El tipo de dibujo no decide el alcance.

Al trasladar el conocimiento al Atlas, consultar architecture-profile para entender cómo se organizarán las arquitecturas nombradas previstas en el Knowledge Map. Conservar el vocabulario de la fuente cuando se explica su perspectiva.

Recorrido para evaluar una propuesta

Problem and context
→ Scope
→ Decisions and constraints
→ Forces and trade-offs
→ Compatibility with other approaches
→ Evidence and consequences

architectural-drivers permite recuperar las necesidades que justifican la propuesta. architectural-significance ayuda a distinguir compromisos sistémicos de decisiones encapsuladas. architecture-vs-design explica por qué esa frontera no se reduce a alto o bajo nivel.

La regla de navegación es no clasificar arquitectura solamente por la etiqueta. Volver al problema si la discusión se limita a decidir cómo debe llamarse una aproximación.

Ramas editoriales

Rama del Knowledge Map	Foco	Cobertura y continuación
Architecture Profiles	Arquitecturas nombradas como paquetes de decisiones.	architecture-profiles compara Monolith, Modular Monolith, Service-Based, SOA y Microservices. event-driven-architecture y serverless-architecture desarrollan perfiles componibles de interacción y ejecución gestionada.
Internal Structure	Organización interna y reglas de dependencia.	internal-structure conecta Layered, la familia Ports and Adapters, Vertical Slice, Microkernel, plugins, Pipe and Filter y criterios de partición de código.
Presentation Patterns	Organización de presentación y cliente.	presentation-patterns compara MVC, MVP y MVVM, sus variantes y composición con estructura interna.
Patterns and Refactoring	Soluciones de diseño con valor práctico.	design-patterns conecta las familias GoF y pattern-selection, sin materializar todo el catálogo como páginas individuales.

Los perfiles y la estructura interna actuales tienen recorridos propios. Los ejemplos pendientes se mencionan en texto normal para preparar navegación futura sin enlazar documentos inexistentes.

Composición y preguntas frecuentes

Para «¿Microservices es un patrón?», ir a architecture-pattern-terminology. La página compara usos de fuentes y explica por qué el Atlas organiza microservices como Architecture Profile.

Para «¿Microservices o Hexagonal?», revisar primero alcance. Un servicio puede usar ports-and-adapters, cuya formulación histórica explica hexagonal-architecture, y utilizar Strategy localmente. Las aproximaciones pueden coexistir; la combinación necesita justificación y compatibilidad de compromisos.

Para «¿cuál es más avanzado?», volver a architectural-drivers. El valor depende de necesidades, restricciones, consecuencias y capacidades del equipo. Ninguna etiqueta constituye una escala universal de madurez.

Relación con los fundamentos

architecture-foundations conecta contexto, arquitectura, significancia, drivers y pensamiento sistémico. Este mapa continúa ese recorrido hacia terminología y reutilización de soluciones.

La disambiguación mantiene las diferencias entre fuentes; los canónicos explican conceptos; el MOC ofrece caminos de lectura. architecture-profiles y internal-structure conectan la cobertura concreta actual, sin crear una taxonomía rígida ni cerrar anticipadamente preguntas que requieren contexto.