Architectural Style vs Architecture Profile

Architectural Style y Architecture Profile no representan dos categorías universales en competencia. Style es un concepto reconocido en la literatura de software architecture, con definiciones variables. Profile es una convención editorial propia del Atlas para documentar arquitecturas nombradas como paquetes de decisiones sobre múltiples ejes.

Una misma aproximación puede ser descrita como estilo por una fuente y representada como perfil por el Atlas. Ambas afirmaciones pueden ser correctas: responden preguntas distintas. Clasificación de la fuente ≠ ubicación en el Atlas. La organización editorial conserva el vocabulario original; no reescribe citas ni convierte diferencias nominales en desacuerdos técnicos.

Dos niveles que conviene separar

En la literatura aparecen Architectural Style, Architectural Pattern, Architecture y Architectural Approach. Su sentido depende del autor, el propósito y el alcance examinado. En el Atlas, Architecture Profiles, Internal Structure, Presentation Patterns y Design Patterns organizan recorridos y fuentes canónicas. Algunos nombres coinciden con términos externos; esa coincidencia no transforma todas las ramas en una taxonomía universal.

architectural-style suele describir una familia de organizaciones mediante vocabulario de elementos, relaciones y restricciones de composición. Garlan y Shaw desarrollan componentes y conectores admisibles; su sección sobre sistemas por capas muestra un ejemplo de estilo. An Introduction to Software Architecture, secciones 3 y 3.4.

El estilo puede actuar sobre un sistema, subsistema o una vista arquitectónica particular. Views and Beyond distingue estilos de módulos, componentes y conectores, y asignación; también explica composiciones y diferentes vistas de un sistema. Eso no exige describir una implementación completa. P.4 Architecture Styles.

architectural-pattern suele enfatizar problema recurrente, contexto, fuerzas, solución reutilizable y consecuencias. Los énfasis de style y pattern pueden superponerse; Views and Beyond reconoce descripciones de una aproximación con ambos enfoques. Profile pertenece a otro nivel: su autoridad aquí es la convención del Atlas, explicada en architecture-profile y establecida en el Knowledge Map V0.3.

Comparación para recordar

Pregunta	Architectural Style	Architecture Profile
Origen	Literatura de software architecture.	Convención del Atlas.
Propósito principal	Familia de organización y restricciones.	Arquitectura nombrada examinada sobre varios ejes.
¿Término universal?	Reconocido; sus definiciones varían.	No; es específico del Atlas.
¿Excluye al otro?	No.	No.
¿Microservices puede serlo?	Sí; Lewis y Fowler lo llaman style.	Sí; el Atlas lo representa como profile.
¿Fuentes pueden usar otro término?	Sí, según su marco.	Profile conserva esas denominaciones.

La diferencia no es la cantidad de ejes. Un estilo puede restringir numerosas dimensiones y estar especificado con gran detalle. Un perfil puede dejar decisiones abiertas. Profile tampoco es un estilo superior, más completo o mejor, un meta-style ni un superset de estilos. No se deduce que todo estilo deba convertirse en perfil o que todo perfil necesariamente sea un estilo.

Microservices: tres lecturas compatibles

Lewis y Fowler utilizan la expresión “microservice architectural style”. Microservices. Richardson presenta la aproximación como Microservice Architecture pattern, con problema, fuerzas y consecuencias. Catálogo de Richardson.

El Atlas representa microservices con kind: architecture-profile para analizar conjuntamente límites de servicios, datos, interacción, deployment, operación y evolución. Es un contenedor de análisis y documentación; esa clasificación no invalida style o pattern en las fuentes.

Si dos descripciones proponen compromisos incompatibles, hay una diferencia técnica que estudiar. Que usen palabras distintas no basta para demostrarla. Tampoco coincidir en el nombre prueba que describan la misma variante.

El perfil de Microservices no es la arquitectura concreta de Company X. Esa instancia todavía necesita decisiones propias sobre contratos, topología, recursos y requisitos. Puede aproximarse a características del perfil sin materializarlas todas; su conformidad necesita evidencia.

Selección editorial y contraejemplos

Un candidato suele merecer tratamiento como Profile cuando nombra una aproximación reconocible para un sistema o subsistema principal; entenderlo requiere varios Decision Axes; una sola regla estructural perdería significado; y sus consecuencias sobre cualidades, operación y evolución justifican comparación conjunta. Son heurísticas editoriales del Atlas, no una definición universal ni reglas de metadata o validación.

Internal Structure suele ser la ubicación principal cuando la pregunta es cómo organizar responsabilidades y dependencias dentro de una unidad. layered-architecture, ports-and-adapters y vertical-slice-architecture ilustran ese foco, sin establecer una prohibición sobre otros alcances.

Layered es el contraejemplo decisivo: Garlan y Shaw lo presentan como estilo; otras fuentes lo tratan como patrón. El Atlas lo ubica en Internal Structure por la pregunta que su canonical ayuda a razonar. Esa ubicación no niega que sea un estilo.

ports-and-adapters y hexagonal-architecture están en esa misma área. Cockburn presenta su propuesta como patrón y architecture; el Atlas conserva la formulación original y distingue canonical y perspectiva histórica. Hexagonal Architecture. Una rama de navegación no arbitra qué palabras puede usar su autor.

Architectural Pattern sigue siendo útil al examinar problema, contexto, fuerzas y consecuencias. Estar fuera de una rama de patrones no impide que una fuente llame patrón a la aproximación.

Decision Axes como representación común

architecture-decision-axes organiza las dimensiones para comparar perfiles: decomposition, dependency-structure, communication, coordination, data-ownership, isolation, tenancy, deployment, execution-model y scaling.

La lectura de un estilo pregunta qué vocabulario y restricciones caracterizan esa familia. La lectura editorial de un perfil pregunta qué respuestas o tendencias aporta la aproximación en esas dimensiones, qué variantes admite y qué decisiones permanecen abiertas. Los ejes ayudan a comparar compromisos, sin garantizar beneficios por el nombre.

Este esquema explica el Atlas; no es un metamodelo estándar de la industria. Solamente algunas aproximaciones reciben representación como Profile:

Terminología de las fuentes
Style / Pattern / Architecture / Approach
                  |
        describe aproximaciones nombradas
                  |
        selección editorial del Atlas
                  |
           Architecture Profile
                  |
        evaluación sobre Decision Axes

Ejemplos de ubicación

Los términos externos de esta tabla son usos posibles según la fuente, no denominaciones que todo autor comparta.

Aproximación	La literatura puede llamarla	Ubicación principal en el Atlas
microservices	Style / pattern / architecture.	Architecture Profile.
modular-monolith	Architecture / approach.	Architecture Profile.
layered-architecture	Style / pattern.	Internal Structure.
ports-and-adapters	Architecture / pattern.	Internal Structure.
model-view-controller	Pattern / architectural pattern.	Presentation Patterns.
event-driven-architecture	Style / architecture.	Architecture Profile.

Una fuente puede describir event-driven-architecture como estilo y el Atlas representarlo como Profile: su realización afecta varias dimensiones. Son descripciones compatibles; su canonical materializa la ubicación prevista por el Knowledge Map. serverless-architecture también se representa como Profile; fuentes que lo llaman computing model, paradigm o architecture conservan su terminología. Su canonical examina delegación de responsabilidades sin reducirlo a FaaS.

Composición sin jerarquía de categorías

La convención evita presentar Microservices vs Layered como alternativas obligatorias para la misma pregunta. Puede haber un sistema Microservices, servicios organizados con Ports and Adapters, un frontend MVC y Strategy dentro de un componente. Cada elección responde una pregunta situada.

Esa composición no establece Profile > Style > Pattern > Design Pattern. Tampoco recomienda sumar nombres: hay que comprobar contratos, restricciones y compatibilidad. architecture-pattern-terminology conserva el contexto terminológico; architecture-patterns y architecture-profiles permiten continuar hacia conceptos y comparaciones concretas.