Architectural Styles, Architectural Patterns, and Design Patterns

Por qué existe esta página

Style, architectural pattern, architecture y design pattern no se utilizan de manera totalmente consistente entre autores. Esta página permite interpretar sus usos, reconocer diferencias útiles y conocer la convención editorial del Atlas. No busca declarar qué autor tiene derecho a usar cada palabra.

Garlan y Shaw hablan de patrones o estilos arquitectónicos al presentar organizaciones recurrentes. Documenting Software Architectures: Views and Beyond distingue el énfasis estructural de un estilo del contexto-problema-solución de un patrón, pero reconoce que una aproximación puede documentarse de ambas formas. P.4 Architecture Styles, apartado Coming To Terms.

La conclusión práctica es conservar fuente y alcance. Una discrepancia nominal puede reflejar un marco diferente; una discrepancia sobre responsabilidades, restricciones o garantías necesita análisis técnico.

Comparación orientativa

Architectural Style, Architectural Pattern y Design Pattern son términos presentes en la literatura. Architecture Profile tiene otro origen: es la convención editorial del Atlas. La tabla compara papeles prácticos; no afirma que compartan una taxonomía externa universal. architectural-style-vs-architecture-profile desarrolla esa distinción.

Concept	Primary concern	Typical scope	Captures problem/forces?	Atlas usage
architectural-style	Vocabulario y restricciones de organización.	Sistema o subsistema.	No siempre explícitamente; puede incluirlos.	Término conceptual de la literatura.
architectural-pattern	Respuesta reutilizable con contexto y consecuencias.	Estructura arquitectónicamente significativa.	Habitualmente sí.	Solución reutilizable de alcance arquitectónico.
architecture-profile	Paquete de decisiones sobre varios ejes.	Sistema o subsistema principal.	Permite evaluar motivación y decisiones combinadas.	Convención para arquitecturas nombradas previstas en el mapa.
design-pattern	Solución recurrente de diseño y colaboración.	Habitualmente dentro de módulos o componentes.	Sí, con intención y aplicabilidad.	Software Design and Modeling.

La tabla no es una definición matemática ni un árbol donde cada nombre tiene una única casilla universal. Un estilo o un patrón puede involucrar múltiples ejes; un Design Pattern puede tener consecuencias significativas. El profile expresa cómo el Atlas organiza ciertas arquitecturas nombradas, no una propiedad que necesariamente las separe de toda la literatura.

Diferencias útiles sin fronteras artificiales

Para interpretar style, buscar qué tipos de partes y relaciones permite, y qué reglas restringen su combinación. Para interpretar architectural pattern, buscar además el problema y las fuerzas que explican esa solución. Ambas lecturas pueden complementarse.

Para design pattern, observar participantes, colaboración e intención dentro del contexto de diseño. No debe identificarse con «una solución pequeña»: una colaboración local puede establecer un contrato importante. architecture-vs-design y architectural-significance explican ese continuo.

Architecture puede nombrar la arquitectura concreta de un sistema o, en una expresión como «Layered Architecture», una aproximación general. El nombre solo no indica si hablamos de una instancia, una familia o una solución reutilizable. software-architecture permite recuperar esa diferencia.

Layers / Layered Architecture

La misma aproximación nombrada puede llamarse style o pattern según la fuente. Garlan y Shaw incluyen Layered Systems entre estilos; el informe del SEI Modifiability Tactics presenta Layers Pattern y reproduce material de POSA. Sección 8.

Esto no obliga a elegir un ganador terminológico. Hay que preguntar qué reglas de dependencia describe cada versión, qué alcance organiza y qué consecuencias analiza. Diferencias de variantes pueden ser relevantes aunque ambas compartan etiqueta.

El Knowledge Map ubica layered-architecture en Software Architecture / Internal Structure. Su canonical explica decisiones, alcance y trade-offs. Esa ubicación editorial no pretende resolver si toda fuente debe llamarla estilo o patrón.

¿Microservices es un patrón o un estilo?

Se encuentra descrito como architectural style, architectural pattern, architecture o architectural approach. Hay ejemplos primarios de los dos primeros usos: Lewis y Fowler presentan el microservice architectural style; Chris Richardson titula su descripción Microservice Architecture pattern. Lewis y Fowler, Richardson.

Por tanto, la respuesta universal «sí, es un patrón» o «no, nunca es un patrón» pierde contexto. Conviene indicar autor, definición y pregunta que se está tratando. Usar «microservices architectural style» no es incorrecto por diferir de la organización editorial del Atlas.

Para el Atlas, microservices se documenta como Architecture Profile, con kind: architecture-profile. Es un paquete que relaciona límites de servicios, deployment, comunicación, datos, evolución, aislamiento y operación. El canonical architecture-profile explica esa convención; architecture-profiles compara ejemplos concretos sin convertir sus diferencias en categorías universales.

El nombre tampoco garantiza independencia real o una mejora de todas las cualidades. Deben describirse las decisiones efectivas y sus consecuencias en el sistema concreto.

Clean, Hexagonal y Onion

El Knowledge Map agrupa clean-architecture, hexagonal-architecture y onion-architecture en Internal Structure / Ports and Adapters Family. ports-and-adapters es el canonical de la aproximación de Cockburn; Hexagonal es una Perspective Note sobre su formulación original, no un patrón competidor. Onion y Clean comparten preocupaciones con esa aproximación, pero no son sinónimos perfectos. internal-structure compara énfasis y reglas reales.

Cockburn plantea Ports and Adapters para separar la aplicación de dispositivos externos y facilitar ejecución y pruebas con adaptadores. Artículo original de Hexagonal Architecture. Martin enfatiza dependencias dirigidas hacia políticas internas en The Clean Architecture; Palermo relaciona Onion con un núcleo rodeado por infraestructura en The Onion Architecture, parte 1.

Microservices condiciona principalmente organización entre servicios y unidades desplegables; esas aproximaciones internas pueden aplicarse dentro de una unidad. La distinción es de preocupación y alcance, no una exclusión universal de otros usos.

Ninguna exige necesariamente crear servicios distribuidos. Tampoco elegir Microservices determina automáticamente la estructura interna de cada servicio.

MVC, MVP, MVVM y GoF

MVC, MVP y MVVM quedan en Frontend and Client Architecture / Presentation Patterns, según el mapa. Organizan preocupaciones de presentación; no ofrecen el mismo paquete de decisiones que Microservices ni son equivalentes a una solución de creación como Factory Method. presentation-patterns compara sus responsabilidades y mecanismos de sincronización, incluyendo MVC clásico/Web y variantes de MVP, sin imponer una clasificación universal por tamaño.

POSA utiliza MVC para ilustrar separación entre interfaz y funcionalidad. Vista previa del capítulo 1. Esta página no desarrolla sus variantes ni afirma que toda implementación de un framework comparta la misma semántica.

GoF es una referencia de Design Patterns, con categorías creational-patterns, structural-patterns y behavioral-patterns. No debe confundirse ese catálogo con toda la arquitectura ni con el universo de patrones. pattern-selection comienza por problemas y fuerzas; tampoco se crean sus 23 entradas anticipadamente.

Composición entre dimensiones y alcances

Una combinación posible es:

System
└── Microservices architecture profile
    └── Order Service
        └── Hexagonal internal structure
            └── Application code
                └── Strategy design pattern

También puede coexistir Event-Driven Architecture con Microservices, Hexagonal Architecture, CQRS y Strategy, porque esas elecciones pueden actuar sobre preocupaciones distintas. Es un ejemplo de composición, no una recomendación ni una afirmación de compatibilidad automática para cualquier variante.

Antes de combinarlas, identificar el alcance de cada regla y si sus compromisos se contradicen. Una dependencia directa puede violar una frontera interna; un modelo compartido de datos puede dificultar evolución independiente entre servicios. Tener etiquetas compatibles no basta.

Cómo clasificar sin perseguir etiquetas

La regla editorial central es no clasificar arquitectura solamente por la etiqueta. Ante Microservices, Layered, Hexagonal, Event-Driven, MVC, CQRS, Repository o Strategy, preguntar:

1. ¿Qué problema resuelve y en qué contexto?
2. ¿Qué sistema o parte organiza?
3. ¿Qué decisiones y dependencias restringe?
4. ¿Qué fuerzas, consecuencias y trade-offs explicita?
5. ¿Puede coexistir con otra aproximación y bajo qué condiciones?

Repository también puede tener sentidos distintos según tradición; mencionar su nombre no crea aquí su canonical. Lo mismo vale para todos los ejemplos pendientes.

Si dos fuentes usan palabras diferentes, comparar sus compromisos antes de declarar una contradicción. Si dos fuentes usan la misma palabra para alcances distintos, conservar esa diferencia en la explicación. architecture-patterns organiza la navegación; los canónicos desarrollan cada concepto sin convertir esta disambiguación en un catálogo de soluciones concretas.