Architectural Style
Qué significa
Architectural Style describe una familia de organizaciones arquitectónicas mediante vocabulario y restricciones compartidos. En el uso académico de Garlan y Shaw, un estilo caracteriza tipos de componentes y conectores y las reglas que permiten combinarlos. No identifica una implementación específica ni una tecnología. An Introduction to Software Architecture, sección 3.
El término tiene una historia más precisa que «el aspecto que tiene un diagrama». Nombrar un estilo permite comunicar qué relaciones son admisibles y qué compromisos orientan la organización. software-architecture sitúa esas estructuras dentro de decisiones, propiedades y preocupaciones del sistema.
La literatura no utiliza de forma completamente uniforme architectural style y architectural pattern. Garlan y Shaw emplean ambos términos cercanamente en su introducción. El Atlas conserva esa variación y usa architecture-pattern-terminology para explicarla.
Vocabulario, relaciones y restricciones
Una lectura práctica de una descripción de estilo puede organizarse mediante estas preguntas:
| Aspecto | Pregunta para la arquitectura que estamos analizando |
|---|---|
| Vocabulario de elementos | ¿Qué roles reconoce y qué responsabilidad tiene cada uno? |
| Conectores | ¿Qué interacciones permite y qué significado tienen? |
| Relaciones | ¿Quién puede usar, invocar o enviar información a quién? |
| Restricciones | ¿Qué combinaciones o comportamientos excluye? |
| Reglas de composición | ¿Cómo se agregan partes sin incumplir los compromisos? |
| Topología | ¿Qué formas de conexión admite o prohíbe? |
| Estructura de interacción | ¿Cómo fluye información y quién controla la ejecución? |
Las preguntas ayudan a examinar una instancia; no obligan a que todos los autores usen exactamente esta ficha. Fielding enfatiza conjuntos coordinados de restricciones sobre elementos y relaciones, y admite estilos enfocados en determinados aspectos de una arquitectura. Dissertation, sección 1.5.
Así, una restricción puede afectar dependencias de código, intercambio durante ejecución o una combinación específica. Conviene aclarar cuál, en lugar de asumir que toda relación representa llamadas de red.
Familia e instancia concreta
Una familia admite variaciones dentro de sus compromisos. Documenting Software Architectures: Views and Beyond explica estilos como especializaciones de tipos de elementos y relaciones sujetas a restricciones; distintas instancias pueden elegir números, protocolos y contenidos diferentes. P.4 Architecture Styles.
Por ejemplo, una aplicación puede organizar responsabilidades en tres grupos y otra en cinco. El número no demuestra que compartan una regla de dependencia. Dos dibujos parecidos pueden admitir relaciones incompatibles; dos dibujos distintos pueden respetar la misma regla.
La arquitectura concreta todavía necesita asignar responsabilidades, seleccionar tecnologías y resolver requisitos propios. El nombre de la familia reduce parte del espacio de decisiones, pero no completa el diseño.
Ejemplos históricos, sin catálogo anticipado
Pipe and Filter, Layered, Client-Server y organizaciones basadas en eventos aparecen en la literatura como formas recurrentes de organización. Sirven para reconocer que vocabulario y reglas varían: transformación y flujo de datos, dependencias entre niveles, roles de interacción o notificación.
Esos nombres no garantizan propiedades por sí solos. Una separación denominada «por capas» puede conservar accesos que contradicen las restricciones declaradas. Una organización con clientes y servidores necesita especificar contratos y capacidad antes de evaluar comportamiento.
Aquí se mencionan como ejemplos; sus documentos individuales tendrán un alcance posterior. No se infiere una taxonomía universal ni se asigna un único estilo a toda arquitectura.
Ejemplo de lectura de restricciones
Supongamos un procesamiento documental con etapas de normalización, validación y exportación. Una propuesta exige que cada etapa reciba documentos por un contrato uniforme y emita resultados sin consultar la representación privada de otra etapa.
Lo útil de esa regla es permitir preguntar qué cambios quedan encapsulados. Si una etapa empieza a leer directamente el almacenamiento interno de otra, puede romper una expectativa de sustitución aunque el dibujo mantenga la misma secuencia.
También hay decisiones pendientes: tamaño de documentos, manejo de errores, orden de procesamiento, datos acumulados y plazo de ejecución. El esquema organizativo no resuelve automáticamente esas necesidades. Este ejemplo ilustra cómo leer compromisos, sin desarrollar un canonical de procesamiento por filtros.
Style y Pattern
architectural-pattern enfatiza un problema recurrente, contexto, solución y consecuencias. El estilo suele destacar la organización admisible. Es una diferencia de énfasis útil, no una frontera que todos los autores respeten.
Una descripción de estilo puede incluir motivación y trade-offs. Un catálogo de patrones puede expresar su solución mediante el mismo vocabulario y restricciones. Por eso, exigir que un estilo jamás describa problemas o que un patrón nunca caracterice una familia produciría distinciones artificiales.
Para interpretar una fuente, conviene conservar su marco y preguntar qué está explicando. La clasificación editorial del Atlas complementa la lectura; no corrige retrospectivamente la terminología del autor.
Composición y alcance
Diferentes organizaciones pueden actuar sobre porciones o relaciones distintas del sistema. Una organización global puede coexistir con estructuras internas diferentes en cada parte. La composición requiere revisar compatibilidad entre las restricciones, no simplemente sumar nombres.
Si una regla impide una dependencia que otra propuesta necesita, hay un conflicto real que resolver. Si cada regla actúa sobre un alcance diferente, pueden coexistir. architectural-significance ayuda a identificar cuándo esa combinación condiciona compromisos del conjunto.
architecture-profile presenta la convención del Atlas para arquitecturas nombradas que combinan decisiones sobre múltiples ejes. No reemplaza el concepto académico de estilo: permite documentar paquetes complejos sin reducirlos a una sola dimensión.
Style vs Profile
Style es un concepto de la literatura; Profile es organización editorial del Atlas. Una arquitectura puede ser llamada estilo por su fuente y representada como perfil aquí. Ambas lecturas son compatibles: la ubicación conserva la terminología del autor. La diferencia no es cantidad de ejes ni grado de completitud. architectural-style-vs-architecture-profile explica esa asimetría y los criterios de selección.
Cómo usar el concepto
Ante una propuesta, identificar fuente, sistema considerado y reglas efectivas. Luego relacionarlas con architectural-drivers y comprobar qué resultados esperamos obtener. La selección necesita evidencia sobre las cualidades relevantes, no solamente familiaridad con un nombre.
Errores frecuentes son clasificar por el dibujo, equiparar estilo con framework, prometer cualidades sin condiciones y declarar incompatibilidad entre aproximaciones que actúan sobre alcances diferentes. architecture-patterns ofrece navegación; architecture-pattern-terminology compara los usos sin convertirlos en categorías matemáticas.