Architecture Profile
Convención editorial del Atlas
Architecture Profile es una convención editorial propia del Software Engineering Atlas. Designa una arquitectura nombrada como un paquete de decisiones que debe evaluarse sobre múltiples ejes. No afirma que toda la literatura utilice esta expresión con el mismo significado.
El Knowledge Map V0.3 establece esa decisión para evitar clasificar aproximaciones complejas exclusivamente por una dimensión. monolith, modular-monolith, service-based-architecture, service-oriented-architecture y microservices materializan la convención, conservando los usos terminológicos de sus fuentes.
architectural-style y architectural-pattern explican términos reconocidos de la literatura. Un profile permite organizar conocimiento sobre una aproximación nombrada y sus compromisos combinados; no elimina esas otras perspectivas ni constituye una nueva teoría universal de arquitectura.
Profile is not a competing taxonomy
Profile ofrece una representación común del Atlas para determinadas arquitecturas nombradas. Conserva Architectural Style, Architectural Pattern y Architecture como términos de las fuentes: una aproximación puede recibir ambas descripciones sin contradicción. architectural-style-vs-architecture-profile distingue procedencia terminológica y ubicación editorial, con heurísticas de selección que no añaden reglas al schema.
Qué agrupa un perfil
Un perfil reúne decisiones relacionadas que orientan una arquitectura. Algunas caracterizan la aproximación; otras dependen del contexto y deben permanecer abiertas. El nombre ayuda a navegar, pero la descripción necesita distinguir compromisos centrales, variaciones y elecciones de implementación.
No equivale a una receta completa. Dos sistemas que usan el mismo nombre pueden tener contratos, topologías y capacidades operativas diferentes. Una comparación útil debe hacer visibles esas diferencias antes de atribuir resultados al perfil.
Tampoco es una categoría de tecnología. Un framework, broker o proveedor puede implementar partes del diseño. software-architecture explica por qué el stack no sustituye responsabilidades, interacción, restricciones y consecuencias.
Ejes de evaluación
El Knowledge Map considera los siguientes ejes analíticos. Son dimensiones que pueden combinarse, no carpetas mutuamente excluyentes. architecture-decision-axes organiza sus preguntas; separar el análisis no significa que las decisiones dejen de interactuar:
| Eje | Pregunta para un perfil concreto |
|---|---|
| decomposition | ¿Cómo distribuye responsabilidades y unidades del sistema? |
| dependency-structure | ¿Qué dependencias permite y qué cambios conecta? |
| communication | ¿Cómo interactúan sus partes y mediante qué contratos? |
| coordination | ¿Cómo conserva acuerdos o recupera resultados parciales? |
| data-ownership | ¿Quién decide y modifica cada información autoritativa? |
| isolation | ¿Qué efectos separa y qué recursos continúan compartidos? |
| tenancy | ¿Cómo distribuye acceso, estado y capacidad entre clientes? |
| deployment | ¿Qué puede entregarse o revertirse de forma independiente? |
| execution-model | ¿Cuándo, dónde y bajo qué ciclo de vida ejecuta trabajo? |
| scaling | ¿Qué capacidades pueden crecer y qué límites permanecen? |
Un estilo o un patrón también puede involucrar varios ejes; profile señala aquí una convención de organización editorial, no una superioridad ni un alcance necesariamente mayor. Un perfil puede aportar respuestas fuertes a algunos ejes y dejar otros parcialmente abiertos. Eso debe explicitarse, sin completar automáticamente cada celda con una garantía que el nombre no ofrece.
Microservices como ejemplo
Para el Atlas, microservices se documenta como Architecture Profile. No es solamente una opción de decomposition: conecta límites de servicios, deployment, comunicación, autoridad sobre datos, evolución independiente, aislamiento, operación y scaling.
Lewis y Fowler describen Microservices como un architectural style y destacan capacidades de negocio, despliegue independiente y características operativas. Microservices, 2014. Esa expresión es válida dentro de su marco. La convención editorial del Atlas permite examinar el paquete sin reemplazar la terminología de la fuente.
Separar procesos no demuestra independencia efectiva. Si todos deben cambiar juntos o necesitan consultar la misma representación privada, una promesa de evolución independiente requiere análisis adicional. Asimismo, un límite de servicio no garantiza aislamiento frente a dependencias comunes.
Concepto y perfiles concretos
Este canonical explica el concepto editorial; por eso su metadata utiliza kind: concept. El documento microservices utiliza doc_type: canonical y kind: architecture-profile. Son funciones diferentes: explicar la categoría y documentar una aproximación que pertenece a ella.
event-driven-architecture y serverless-architecture materializan también esta convención. La primera enfatiza hechos como mecanismo de interacción; la segunda, delegación de infraestructura, ejecución y capacidad. Pueden combinarse con otros perfiles. architecture-profiles conserva las comparaciones de organización y deployment y ofrece navegación hacia ambas.
La ruta física organiza el conocimiento, pero no determina identidad ni linking. Un perfil puede relacionarse con estructuras internas, prácticas, tecnologías o patrones situados en otras áreas mediante IDs estables.
Ejemplo de comparación situada
Supongamos un producto con un equipo pequeño, un contrato externo compartido y operaciones que modifican conjuntamente varios datos. El requisito inmediato es entregar cambios frecuentes sin perder capacidad de prueba y recuperación.
Comparar un Modular Monolith con Microservices exige preguntar qué independencia necesitamos realmente, dónde aparecen costos de coordinación y qué puede operar el equipo. El análisis no se resuelve contando módulos o servicios. modifiability, testability y deployability permiten distinguir localidad del cambio, evidencia de comportamiento y entrega segura, aun cuando un profile contribuya a las tres.
Una unidad de despliegue compartida podría simplificar operación y exigir coordinación de entregas. Unidades separadas podrían permitir ciertos cambios independientes y añadir contratos, observación y recuperación entre ellas. Los resultados dependen de límites y mecanismos concretos, no de una escala universal de madurez.
architectural-drivers ayuda a relacionar la comparación con necesidades; architectural-significance identifica compromisos que afectarán cambios posteriores. quality-attribute-scenarios concreta los resultados a comparar y quality-attribute-trade-offs examina sus consecuencias conjuntas.
architectural-tactics trata decisiones más enfocadas que pueden participar dentro de un profile. El paquete completo no equivale a una tactic ni garantiza las qualities por su nombre.
architectural-quantum [ADVANCED] examina un alcance de independencia y características arquitectónicas que depende de cohesión y coupling. Una misma etiqueta de profile puede realizar límites distintos; el paquete de decisiones no determina por sí solo el número de quanta.
Composición con otras aproximaciones
Un servicio de un perfil Microservices puede organizar su interior mediante Hexagonal Architecture y usar Strategy en una colaboración local. Event-Driven Architecture puede combinarse con ese perfil para ciertas interacciones. Cada elección responde preguntas diferentes.
No es una recomendación automática de esa combinación. Hay que comprobar compatibilidad de contratos, reglas de dependencia y responsabilidades. Un diseño puede necesitar una comunicación y rechazar otra, o una solución local puede introducir un acoplamiento que contradiga el objetivo global.
architecture-pattern-terminology desarrolla esos casos y sitúa Clean, Hexagonal y Onion en Internal Structure / Ports and Adapters Family, siguiendo el Knowledge Map. MVC, MVP y MVVM tienen su área de Presentation Patterns.
Beneficios, límites y uso
La convención facilita comparar paquetes de decisiones sin forzar una sola clasificación. Permite conservar conexiones entre ejes y expresar que una tecnología o un patrón implementa solo parte de la aproximación.
Tiene un límite: un nombre demasiado amplio puede esconder variantes incompatibles. La descripción debe recuperar problema, alcance, decisiones, alternativas y consecuencias. También necesita señalar qué resultados requieren capacidades adicionales del equipo o del entorno.
No clasificar arquitectura solamente por la etiqueta. Preguntar qué problema resuelve, qué alcance afecta, qué decisiones restringe y qué trade-offs produce. architecture-vs-design ayuda a revisar colaboraciones locales y compromisos sistémicos; architecture-patterns conecta perfiles con patrones y estilos sin imponer una jerarquía universal.