Architecture Profiles

Preguntas para comparar perfiles

Este MOC compara Architecture Profiles y conecta sus posibilidades de composición. architecture-profile explica la convención editorial: son paquetes evaluados sobre múltiples ejes. Las tablas sintetizan tendencias; los canónicos desarrollan condiciones, variantes y consecuencias.

Architecture Profile es terminología editorial del Atlas. Las fuentes pueden llamar a estas aproximaciones estilos, patrones o arquitecturas; aquí reciben una representación común para comparación. architectural-style-vs-architecture-profile explica por qué ambas lecturas son compatibles.

Comenzar por una necesidad. Para fundamentarla, consultar architectural-drivers y architectural-significance. Más servicios no representan automáticamente más madurez; el perfil apropiado depende del problema y de los compromisos que el equipo puede sostener. quality-attributes ofrece el recorrido desde resultados esperados hasta escenarios, prioridades y evidencia para comparar esos paquetes.

Pregunta	Recorrido
¿Qué implica compartir delivery y runtime?	monolith
¿Cómo proteger módulos sin separar deployment?	modular-monolith
¿Qué ofrecen agrupamientos remotos amplios?	service-based-architecture
¿Cómo integrar capacidades y ownership domains?	service-oriented-architecture
¿Qué cuesta la autonomía de servicios?	microservices

Perfil componible: interacción mediante eventos

¿Cómo cambia la arquitectura cuando los eventos se vuelven un mecanismo central de interacción y reacción? event-driven-architecture examina hechos, contratos, coordinación, entrega y operación.

EDA puede componerse con Monolith, Modular Monolith, Service-Based, SOA o Microservices. No se añade como una sexta alternativa excluyente a las matrices siguientes: esas tablas comparan cinco paquetes alrededor de organización y deployment. Esta sección ofrece navegación, sin crear una categoría universal nueva.

Perfil componible: infraestructura y ejecución gestionadas

¿Cómo cambia la arquitectura cuando infraestructura, capacidad de ejecución y lifecycle se delegan fuertemente a una plataforma? serverless-architecture examina responsabilidades conservadas, estado, límites, costo y operación.

Serverless y event-driven-architecture responden preguntas distintas y pueden combinarse. Microservices + Serverless + EDA es una composición posible, no una escala de madurez. Serverless tampoco entra como alternativa excluyente en las matrices estructurales siguientes.

Fronteras, contratos y datos

La comparación se divide en dos tablas para conservar legibilidad. Deployment independiente describe una capacidad efectiva, no la simple existencia de artefactos separados. Los valores son tendencias y dependen de la implementación.

Profile	Deployment boundary	Internal modularity	Communication	Data ownership	Independent deployment
monolith	Frontera común amplia.	Puede ser buena o débil.	Principalmente local, con integraciones externas.	Compartido o delimitado lógicamente.	Habitualmente limitada entre sus partes.
modular-monolith	Release común.	Límites explícitos y protegidos.	Contratos locales; eventos posibles.	Ownership de módulos, storage compartible.	Módulos normalmente entregados juntos.
service-based-architecture	Servicios amplios separados.	Decisión interna de cada servicio.	Remota entre unidades, local dentro.	Puede compartir datos; autoridad por precisar.	Posible, condicionada por contratos y esquema.
service-oriented-architecture	Proveedores y sistemas según contexto.	No prescribe una estructura única.	Interacciones entre capacidades.	Autoridades y compromisos de participantes.	Depende de la arquitectura concreta.
microservices	Servicios delimitados con ciclos propios.	Decisión interna por servicio.	Red y mensajes.	Fuerte énfasis en autoridad lógica privada.	Objetivo central, sostenido por compatibilidad.

Operación, cambio y equipos

Profile	Operational complexity	Fault isolation	Scaling granularity	Change coordination	Team autonomy
monolith	Generalmente menor inventario operativo.	Fallos de runtime pueden propagarse.	Habitualmente la unidad completa.	Release y recursos comunes.	Ownership interno posible; delivery compartido.
modular-monolith	Operación común y disciplina modular.	Encapsulación no aísla recursos.	Unidad común, con límites adicionales posibles.	Contratos internos y entrega conjunta.	Diseño por módulo; operación compartida.
service-based-architecture	Distribución acotada según topología.	Procesos separados; dependencias comunes permanecen.	Servicio amplio.	Menos fronteras, posible acoplamiento de datos.	Por servicio, limitada por acuerdos comunes.
service-oriented-architecture	Integración y gobierno entre capacidades.	Depende de proveedores y middleware.	Servicios y recursos de integración.	Versiones, políticas y acuerdos empresariales.	Depende de ownership y governance.
microservices	Mayor inventario y costos distribuidos frecuentes.	Potencial, requiere protecciones y recursos.	Capacidad delimitada por servicio.	Contratos compatibles; cambios transversales existen.	Fuerte énfasis en autoridad y evolución propias.

Ninguna celda asigna una puntuación. Por ejemplo, menos unidades no garantiza menos complejidad si comparten dependencias difíciles de cambiar; independencia de deployment no asegura aislamiento de datos o fallos.

Matriz simplificada de decision axes

Profile	Decomposition	Communication	Data Ownership	Deployment	Scaling	Isolation	Coordination
Monolith	Componentes del conjunto.	Local y externa.	Variable.	Frontera amplia.	Réplicas comunes.	Runtime frecuente compartido.	Local y externa.
Modular Monolith	Módulos protegidos.	Contratos locales.	Autoridad modular.	Compartido.	Unidad común.	Estructural, no necesariamente operativa.	Contratos y transacciones locales.
Service-Based	Servicios amplios.	Red entre unidades.	Variante compartida o delimitada.	Por servicio.	Servicio amplio.	Parcial y contextual.	Local amplia y distribuida.
SOA	Capacidades ofrecidas.	Interacciones contractuales.	Ownership domains.	Según proveedores.	Según capacidades.	Según topología.	Composición y acuerdos.
Microservices	Responsabilidades delimitadas.	Red y mensajes.	Autoridad por servicio.	Independiente como objetivo.	Por capacidad.	Requiere mecanismos.	Invariantes locales y procesos distribuidos.

architecture-decision-axes permite distinguir decomposition, dependency-structure y communication: unidades, dependencias e intercambio son preguntas relacionadas que no decide una sola etiqueta. coordination, data-ownership e isolation permiten separar resultado conjunto, autoridad sobre estado y contención de efectos. Son las preguntas detrás de esas columnas, no propiedades garantizadas por el nombre del perfil. tenancy, deployment y execution-model distinguen sharing entre clientes, fronteras de instalación y lifecycle del trabajo. scaling examina capacidad ampliable y límites, sin convertir granularidad de servicios en una garantía. Sus recorridos completos están en el MOC de axes. La matriz selecciona ejes para comparar; no convierte los restantes en irrelevantes ni impone un schema adicional.

Recorridos de decisión

Comparar monolith y modular-monolith cuando la duda es estructura interna: compartir deployment no decide si los límites están protegidos. Comparar service-based-architecture y microservices cuando importa separar capacidades: revisar granularidad, datos y change coupling, no contar servicios.

Para SOA frente a Microservices, comenzar por service-oriented-architecture. Ambos comparten orientación a capacidades y contratos, con énfasis y prácticas variables. SOA no se coloca como un peldaño en una línea de mayor distribución.

Una revisión práctica pregunta qué necesita entregarse por separado, qué invariantes requieren coordinación, dónde reside autoridad sobre datos, qué recursos siguen compartidos y quién responderá ante fallos. Después contrasta beneficios con costo operativo y esfuerzo de pruebas.

Composición y continuación editorial

Architecture Profile del sistema
├── Unidad con estructura interna Hexagonal
├── Unidad con estructura interna Layered
└── Unidad con estructura interna Vertical Slice

internal-structure permite comparar responsabilidades y dependencias dentro de esas unidades. Layered, Ports and Adapters y Vertical Slice actúan sobre un eje diferente del perfil; las combinaciones necesitan reglas compatibles.

El ejemplo no prescribe esas estructuras. event-driven-architecture desarrolla interacción y reacción mediante hechos y puede coexistir con cualquiera de los cinco perfiles. serverless-architecture desarrolla delegación de infraestructura, ejecución y capacidad; puede componerse con EDA y otros perfiles sin incorporarse a una escala Monolith→Microservices.

architecture-patterns y architecture-pattern-terminology permiten volver a la distinción entre perfiles, estilos, patrones e implementación interna. La comparación conserva esas dimensiones separadas sin exigir que sean mutuamente excluyentes.