Niveles de arquitectura

1. Niveles de Abstracción en la Arquitectura

La arquitectura de software se clasifica en tres niveles de abstracción principales, los cuales definen el alcance del diseño y la comunicación requerida:

NivelAlcance y EnfoqueTipo de DiseñoAlcance de Comunicación
Aplicación (Application)Una sola aplicación o servicio.Detallado y de bajo nivel.Interno (un solo equipo de desarrollo).
Solución (Solution)Conjunto de aplicaciones que satisfacen una necesidad de negocio.Mixto (alto y bajo nivel).Intermedio (múltiples equipos de desarrollo).
Empresarial (Enterprise)Ecosistema de soluciones de toda la organización.Abstracto y de alto nivel.Global (toda la organización).

2. Arquitectura de Aplicaciones

Consiste en definir el mapa y las interacciones de los componentes de un software para satisfacer sus requisitos técnicos y operativos.

Beneficios Principales

  • Reducción de Costos: Identifica y elimina componentes redundantes y procesos duplicados en la fase de diseño.
  • Eficiencia Temprana: Detecta cuellos de botella y brechas funcionales antes de que el código entre a producción.
  • Modularidad e Interoperabilidad: Permite actualizar módulos de forma independiente sin desestabilizar el sistema completo.

Patrones de Arquitectura vs. Patrones de Diseño

  • Patrones de Arquitectura (Nivel Alto): Definen la estructura global del sistema (ej: capas, microservicios, eventos).
  • Patrones de Diseño (Nivel Bajo): Resuelven problemas recurrentes de interacción entre clases y objetos individuales (ej: Singleton, Observer, Factory).

3. Arquitectura de Soluciones (SA)

Actúa como el puente entre la Arquitectura Empresarial (Estrategia) y la Arquitectura Técnica (Ejecución). Su objetivo es diseñar respuestas tecnológicas a enigmas específicos del negocio.

Diferencias Clave: SA vs. EA

  • Arquitectura Empresarial (EA): Enfocada en la estrategia a largo plazo, racionalización del portafolio de aplicaciones, mitigación de riesgos globales y optimización de costos generales de TI. Limitado enfoque en el detalle técnico.
  • Arquitectura de Soluciones (SA): Enfocada en la planificación detallada y la ejecución inmediata de un proyecto para satisfacer requisitos funcionales y de negocio concretos.

Los 6 Pilares de la Arquitectura de Soluciones

  1. Arquitectura de Negocios: Traduce los objetivos empresariales mediante mapas de capacidades del negocio.
  2. Arquitectura de la Información: Estructura las interfaces para optimizar la usabilidad y navegación del usuario.
  3. Arquitectura de Seguridad: Garantiza que los nuevos sistemas cumplan con las normativas e infraestructuras de seguridad corporativas.
  4. Arquitectura del Sistema: Diseña entidades de software y procesos automatizados (clave en modelos SaaS).
  5. Arquitectura de Aplicaciones: Define la integración e interacción entre herramientas de software individuales.
  6. Arquitectura tecnológica: Detalla la infraestructura física o de nube necesaria para soportar la solución.

4. Arquitectura de Software Empresarial (ESA)

Se centra en coordinar y alinear la infraestructura general de TI con los objetivos del negocio.

Áreas de Responsabilidad

  • Alinear la estrategia tecnológica y los objetivos de negocio corporativos.
  • Diseñar y mejorar continuamente la arquitectura a nivel empresarial.
  • Establecer normas, políticas y estándares de TI.
  • Identificar e incorporar tecnologías disruptivas mitigando riesgos.

Requisitos y Atributos de Calidad (QARs) a Evaluar

  • De Negocio: Adaptabilidad, extensibilidad, cumplimiento de estándares y usabilidad.
  • De Seguridad: Confidencialidad, integridad, disponibilidad y trazabilidad/responsabilidad.
  • De Rendimiento: Escalabilidad (horizontal/vertical), capacidad de respuesta y tasa de transferencia.
  • De Datos: Interoperabilidad y durabilidad de la información.
  • De Mantenimiento: Monitorización, observabilidad y capacidad de prueba (testability).

5. Descripción y Modelado de Sistemas

Para comunicar diseños complejos a partes interesadas técnicas y de negocio, se utilizan herramientas estandarizadas.

El Modelo 4+1 de Kruchten

Permite describir un sistema de software desde 5 perspectivas concurrentes:

  1. Vista Lógica: Describe la funcionalidad del sistema orientada a los usuarios finales (Clases, Objetos).
  2. Vista de Desarrollo (Implementación): Organización de los módulos de software, paquetes y archivos desde el punto de vista del programador.
  3. Vista de Proceso: Modela la concurrencia, rendimiento, sincronización y flujos de control.
  4. Vista Física (Despliegue): Muestra la distribución del software en nodos físicos de hardware y red.
  5. Escenarios (+1): Casos de uso reales que orquestan y validan la consistencia de las otras cuatro vistas.

Diagramas UML Esenciales

  • Diagrama de Componentes (Estructural): Ofrece una vista de pájaro de los módulos del sistema y sus interfaces de conexión (círculos y flechas).
  • Diagrama de Clases (Estructural): Muestra los atributos, métodos y multiplicidades de las entidades. Utiliza modificadores de acceso: + (público), - (privado), # (protegido), y _ (estático).
  • Diagrama de Actividad (Comportamiento): Modela el flujo dinámico de control de un proceso a través de decisiones, forks/joins concurrentes y sincronizaciones.
  • Diagrama de Despliegue (Físico): Muestra la infraestructura de hardware, los servidores de software ejecutándose y sus dependencias de red.
  • Diagrama de Casos de Uso (Comportamiento): Modela las interacciones de los actores (usuarios o sistemas externos) con las funcionalidades principales (óvalos).

6. Patrones Arquitectónicos: Ventajas y Desventajas

A. Arquitectura en Capas (N-Tier)

Divide el sistema en capas horizontales con responsabilidades independientes (típicamente: Presentación, Negocio, Acceso a Datos).

  • Ventajas:
    • Clara separación de conceptos (Separation of Concerns).
    • Componentes modulares fáciles de desarrollar, probar y asignar a distintos roles.
  • Desventajas:
    • Propensión al antipatrón de sumidero (sinkhole), donde las peticiones atraviesan capas sin ejecutar lógica.
    • Tiende a evolucionar en monolitos estrechamente acoplados difíciles de escalar.

B. Arquitectura Cliente-Servidor

Estructura distribuida donde servidores centralizados procesan peticiones enviadas por clientes (ligeros o pesados).

  • Ventajas:
    • Seguridad y control centralizados.
    • Backups y actualizaciones de datos simplificados en el servidor.
  • Desventajas:
    • Punto único de fallo (Single Point of Failure).
    • Riesgo de congestión de red ante picos de demanda.

C. Modelo-Vista-Controlador (MVC)

Patrón de interfaz de usuario que desacopla la lógica de negocio (Modelo), la representación (Vista) y la captura de entradas (Controlador).

  • Ventajas:
    • Bajo acoplamiento y alta cohesión.
    • Permite el desarrollo paralelo de la interfaz y la lógica.
    • Alta reutilización del mismo modelo en múltiples vistas.
  • Desventajas:
    • Curva de aprendizaje inicial.
    • No es apto para orquestar la arquitectura general de sistemas internos o subsistemas complejos de back-end.

D. Arquitectura Orientada a Servicios (SOA)

Construcción de sistemas combinando servicios independientes que se comunican mediante protocolos estándares de red (ej. Web Services).

  • Ventajas:
    • Alta reusabilidad de servicios completos a nivel corporativo.
    • Servicios aislados, autocontenidos y fáciles de probar individualmente.
  • Desventajas:
    • Gran complejidad de gobernanza, orquestación y monitoreo de servicios.
    • Alta sobrecarga (overhead) de procesamiento debido a la comunicación constante por red.

E. Arquitectura de Microservicios

Evolución de SOA. Divide el sistema en una colección de servicios muy ligeros, independientes y con responsabilidades acotadas a un único dominio de negocio.

  • Ventajas:
    • Escalabilidad modular e independiente para los servicios más demandados.
    • Despliegue continuo y ciclos de desarrollo ágiles e independientes.
  • Desventajas:
    • Complejidad técnica y operativa alta en la gestión de redes, consistencia eventual de datos y latencias.
    • Riesgo de caer en el antipatrón de nanoservicios si la granularidad es excesiva.

F. Diseño Guiado por el Dominio (DDD)

Metodología que enfoca el desarrollo en un modelo del negocio compartido, usando un Lenguaje Ubicuo común entre técnicos y expertos de negocio. Clasifica elementos en Entidades (con identidad única), Objetos de Valor (inmutables por su valor) y Raíces Agregadas (controladores de conjuntos de objetos).

  • Ventajas:
    • Elimina fallos de comunicación entre negocio e ingeniería.
    • El código replica fielmente el negocio, facilitando la adaptabilidad ante cambios estratégicos.
  • Desventajas:
    • Elevado coste de tiempo inicial y necesidad de implicación continua de expertos del negocio.
    • Requiere personal técnico experimentado. No apto para dominios sencillos.

G. Arquitectura Dirigida por Eventos (Event-Driven)

El flujo del sistema se rige por la emisión y consumo de cambios de estado (eventos). Se implementa mediante el modelo Publicador-Suscriptor (Broker) o el modelo de Streaming de eventos (Logs).

  • Ventajas:
    • Desacoplamiento absoluto: los emisores no conocen a los receptores.
    • Alta escalabilidad, distribución y procesamiento eficiente de grandes volúmenes de datos en tiempo real.
  • Desventajas:
    • Dificultad para garantizar el orden de procesamiento de eventos.
    • Complejidad de rastreo de flujos de control y depuración de procesos asíncronos.

Referencias y Lecturas Recomendadas: