Architectural Pattern
Qué es
Architectural Pattern es una solución arquitectónica reutilizable para un problema recurrente dentro de un contexto, con consecuencias y trade-offs que necesitan explicitarse. Su valor reside en transmitir razonamiento aplicable, además de una organización reconocible.
Pattern-Oriented Software Architecture, volumen 1, presenta patrones como conocimiento de problemas recurrentes y soluciones extraídas de experiencia; vincula contexto, problema y fuerzas con la solución. El origen conceptual se relaciona con Christopher Alexander. POSA, capítulo 1, vista previa del libro.
El SEI también describe patrones como soluciones conceptuales a problemas de diseño en contexto y caracteriza patrones arquitectónicos mediante elementos, interacciones y restricciones. A Holistic View of Architecture. La solución debe afectar una preocupación arquitectónicamente significativa, no depender simplemente de su extensión en código.
Más que una estructura repetida
Observar una forma recurrente no explica todavía por qué conviene aplicarla. Un patrón necesita conectar esa forma con un problema y unas condiciones. Un diagrama aislado omite decisiones sobre cuándo funciona la solución, qué fuerza prioriza y qué dificultades introduce.
Las descripciones varían entre catálogos. Una ficha útil para leer o evaluar un patrón puede incluir:
| Parte | Qué debe permitir entender |
|---|---|
| Context | Situación y supuestos donde aparece el problema. |
| Problem | Necesidad que permanece sin resolver. |
| Forces | Presiones y objetivos que pueden entrar en tensión. |
| Solution | Responsabilidades, interacciones y restricciones propuestas. |
| Consequences | Resultado esperado y obligaciones que deja la solución. |
| Trade-offs | Beneficios obtenidos y costos o limitaciones aceptados. |
No es una plantilla obligatoria del Atlas. Diferentes fuentes pueden repartir esta información entre intención, motivación, aplicabilidad, solución y contexto resultante. Importa recuperar el razonamiento, no exigir idénticos encabezados.
Problema, fuerzas y respuesta
Un problema plantea qué necesitamos lograr. Las fuerzas explican por qué no basta cualquier respuesta: pueden exigir sustituir una integración, mantener contratos, limitar coordinación o trabajar con capacidades existentes.
La solución distribuye responsabilidades y establece reglas. Sus consecuencias indican qué propiedades puede favorecer y bajo qué condiciones. Los trade-offs explicitan costos, complejidad desplazada o necesidades que no quedan satisfechas.
architectural-drivers relaciona esas influencias con el sistema concreto. Una solución reconocida en otros proyectos no demuestra que nuestros drivers coincidan con los del patrón. La aplicación necesita justificar esa correspondencia.
Ejemplo de evaluación
Supongamos una aplicación que debe admitir nuevos medios de importación sin reescribir las reglas de validación de documentos. Actualmente, esas reglas consultan directamente detalles de cada proveedor.
El problema es la propagación de cambios externos hacia comportamiento que queremos preservar. Las fuerzas incluyen facilidad de prueba, plazo de integración y complejidad que un equipo pequeño puede operar.
Una propuesta separa contratos de interacción de las traducciones específicas de cada proveedor. Puede facilitar sustitución y pruebas, pero exige mantener traducciones y decidir qué diferencias representan necesidades del negocio. Si los proveedores tienen semánticas incompatibles, una interfaz uniforme no elimina esa incompatibilidad.
Lo importante del ejemplo no es reconocer una figura geométrica ni bautizar un patrón nuevo. Es mostrar la conexión problema-contexto-solución-consecuencias que permite evaluar una aproximación conocida sin copiarla mecánicamente.
Architectural Style y vocabulario variable
architectural-style suele enfatizar vocabulario y restricciones de organización. Architectural Pattern suele enfatizar una respuesta a un problema y sus fuerzas. Los énfasis se superponen y no forman una taxonomía universal.
Layers es un caso verificable: Garlan y Shaw presentan sistemas por capas entre estilos; el SEI reproduce de POSA el Layers Pattern, con problema, fuerzas y solución. Modifiability Tactics, sección 8. El cambio de vocabulario no implica necesariamente que se describan ideas incompatibles.
Pipes and Filters y Microkernel también aparecen dentro de marcos de estilos o patrones. Una fuente puede llamar a una aproximación arquitectura, patrón o estilo según lo que pretende explicar. architecture-pattern-terminology permite interpretar esas denominaciones conservando su contexto.
Diferencia respecto de Design Pattern
design-pattern describe soluciones recurrentes de diseño, frecuentemente centradas en participantes y colaboraciones dentro de una parte del software. La distinción útil se apoya en alcance y consecuencias.
Una elección sobre quién depende de quién a través de una parte significativa del sistema puede requerir tratamiento arquitectónico. Elegir una colaboración interna que conserva contratos externos suele admitir razonamiento local. El número de clases o cajas no determina esa frontera.
Un Design Pattern puede participar en la implementación de una solución arquitectónica. También puede volverse significativo si establece un contrato transversal. architecture-vs-design desarrolla ese continuo: ninguna etiqueta reemplaza examinar el impacto real.
Patrón, implementación y arquitectura concreta
Un patrón no es código reutilizable listo para instalar. Tampoco equivale a una librería, framework o producto. Una implementación puede facilitar ciertas colaboraciones, pero las responsabilidades y restricciones deben conservarse en el sistema construido.
Usar nombres de carpetas compatibles con el patrón no demuestra conformidad. Una prueba de comportamiento, revisión de dependencias o escenario de cambio puede revelar que los compromisos centrales no se cumplen.
La arquitectura concreta combina decisiones específicas y puede emplear varias soluciones. architecture-profile explica cómo el Atlas organizará arquitecturas nombradas que agrupan decisiones sobre múltiples ejes. Ese perfil puede apoyarse en patrones sin ser intercambiable con cada uno.
Composición y trade-offs
Combinar aproximaciones necesita identificar dónde actúa cada una. Separar estructura interna, comunicación entre unidades y colaboraciones locales puede permitir coexistencia. Pero dos soluciones que exigen autoridades diferentes sobre los mismos datos pueden entrar en conflicto aunque sus nombres parezcan complementarios.
Cada patrón introduce obligaciones. Agregar intermediarios puede facilitar adaptación y aumentar caminos de diagnóstico. Restringir dependencias puede favorecer evolución y exigir más contratos. Debe compararse el costo completo con el problema que realmente existe.
Cuándo resulta útil
Usar patrones para compartir experiencia, explorar alternativas y examinar consecuencias antes de comprometer una solución. Su nombre sirve como punto de entrada a una conversación, no como argumento suficiente para cerrar la decisión.
Evitar aplicar un catálogo como checklist, elegir por popularidad o presentar beneficios incondicionales. También conviene evitar redefinir un patrón hasta que pierda los compromisos que hacían útil su nombre.
La regla editorial es no clasificar arquitectura solamente por la etiqueta. architectural-significance ayuda a reconocer el alcance; architecture-patterns conecta fuentes, conceptos y preguntas sin crear anticipadamente documentos de cada patrón concreto.