JAVA AVANZADO

Clase 20
Diseño de Arquitectura
de Proyectos
Les damos la bienvenida
Vamos a comenzar a grabar la clase
 Introducción a las arquitecturas de software en Java

Una arquitectura de software define cómo se organiza un sistema, especifica las partes
del sistema y cómo interactúan entre sí.

La elección de la arquitectura puede impactar en la mantenibilidad, la escalabilidad, el

rendimiento, la seguridad y otras características cruciales de un sistema.
 Arquitectura Monolítica en Java
● Definición: En una arquitectura monolítica, todo el software se construye como un
único sistema.
● Ventajas: Facilidad de desarrollo y pruebas, despliegue simplificado, transacciones
más simples.
● Desventajas: Pueden ser difíciles de mantener y escalar, acoplamiento alto,
cambios en un área pueden afectar a todo el sistema.
● Ejemplo: Un sistema de gestión de inventario donde todos los módulos (UI,
administración de inventario, facturación, etc.) se alojan en una única aplicación.
 Arquitectura Orientada a Servicios (SOA) en Java
● Definición: SOA agrupa la funcionalidad del software en servicios autónomos y
reutilizables.
● Ventajas: Alta reutilización, flexibilidad para usar diferentes tecnologías,
modularidad.
● Desventajas: Mayor complejidad, necesidad de un buen diseño de servicios,
problemas de rendimiento potenciales.
● Ejemplo: Un sistema bancario donde cada servicio (transferencias, depósitos,
retiros) se desarrolla como un servicio separado.
 Arquitectura de Microservicios en Java
● Definición: Similar a SOA pero con servicios más pequeños y más independientes.
● Ventajas: Desacoplamiento alto, escalabilidad, la falla de un servicio no afecta a
los demás.
● Desventajas: Más difícil de administrar, requerimientos de red más altos,
coordinación de transacciones más compleja.
● Ejemplo: Netflix, donde cada parte de su plataforma (streaming, recomendaciones,
pagos) se maneja como un microservicio independiente.
 Arquitectura Orientada a Eventos en Java
● Definición: Esta arquitectura se centra en el manejo de eventos. Los componentes
de software interactúan al generar y recibir eventos.
● Ventajas: Alta escalabilidad, flexibilidad, facilidad para manejar operaciones
asíncronas.
● Desventajas: Rastreo y manejo de errores más difícil, depende en gran medida del
diseño de eventos.
● Ejemplo: Un sistema de comercio electrónico que genera eventos al realizar
acciones como agregar al carrito, comprar, calificar productos, etc.
 Introducción a CQRS

● Definición: CQRS (Command Query Responsibility Segregation) es un patrón de

diseño que separa las operaciones de lectura (queries) y escritura (commands) en
diferentes modelos.
● Ventajas: Mayor flexibilidad, alto rendimiento y escalabilidad, facilita la
implementación de sistemas distribuidos.
 Commands (Comandos)
● Definición: Los comandos representan las operaciones que modifican el estado de
nuestro sistema. Son acciones que realizan cambios, como Crear, Actualizar o
Eliminar.
● Características: Los comandos pueden ser transaccionales, suelen ser operaciones
más lentas, y se ejecutan de forma secuencial.
 Queries en CQRS
● Definición: Las queries son las operaciones que leen el estado de nuestro sistema.
Son acciones que consultan y recuperan datos.
● Características: Las queries pueden ser operaciones rápidas y se ejecutan de forma
más frecuente que los comandos.
 Implementación de CQRS en microservicios

● Cada microservicio puede tener su propio modelo de comando y consulta, lo que

permite a los equipos desarrollar, desplegar y escalar cada uno de forma
independiente.
● Ejemplo: Un microservicio de gestión de pedidos en una aplicación de comercio
electrónico puede tener un comando para crear un nuevo pedido y una consulta
para recuperar los detalles del pedido.
 CQRS y Eventos
● CQRS se complementa bien con Event Sourcing, un patrón en el que el estado de
la aplicación se determina a partir de una secuencia de eventos.
● Cuando se emite un comando que modifica el estado de la aplicación, también se
genera un evento que se almacena en un registro de eventos.
● Los servicios de consulta pueden consumir estos eventos para actualizar su estado
y responder a las consultas.
● Ejemplo: Cuando se crea un nuevo pedido en nuestro ejemplo de comercio
electrónico, se genera un evento "PedidoCreado". Los servicios de consulta pueden
consumir este evento para actualizar su estado.
 Clean Architecture
● Definición: "Clean Architecture" es una filosofía de diseño de software propuesta por
Robert C. Martin. Su objetivo es la separación de preocupaciones y el desacoplamiento
de la lógica de negocio de las capas de infraestructura, interfaces de usuario y cualquier
marco o tecnología externa.
● Ventajas: Alta mantenibilidad y testeabilidad, independencia de tecnología y UI,
adaptabilidad.
● Desventajas: Mayor tiempo de desarrollo inicial, mayor complejidad.
● Ejemplo: Una aplicación de reservas de hotel donde cada módulo (usuario, reservas,
pagos) sigue los principios de Clean Architecture.
 Domain-Driven Design (DDD)
● Definición: DDD es una metodología de desarrollo de software que prioriza la
lógica y la complejidad del dominio del problema. Centra el diseño del software en
el modelo del dominio y las reglas de negocio.
● Ventajas: Mayor entendimiento del dominio del problema, comunicación efectiva
entre el equipo técnico y los expertos en el dominio, software más mantentible y
adaptable al cambio.
 Arquitectura Hexagonal
● Definición: También conocida como "puertos y adaptadores", la Arquitectura
Hexagonal se enfoca en la separación de las lógicas de negocio de los detalles
técnicos y los detalles de la interfaz de usuario.
● Ventajas: Flexibilidad, mantenibilidad, facilita la implementación de pruebas
automatizadas.
● Clean Architecture con DDD: Con este enfoque, primero se construyen los
modelos de dominio utilizando DDD. Luego, se diseñan las capas de la Clean
Architecture (Entities, Use Cases, Interface Adapters, Frameworks and Drivers)
para implementar estos modelos.
● Arquitectura Hexagonal con DDD: En este caso, se utilizan los modelos de
dominio DDD para definir los "puertos" (interfaces de la aplicación) y
"adaptadores" (implementaciones de interfaces) en la Arquitectura Hexagonal.
Esto permite probar cada "lado" del hexágono (lógica de negocio, bases de datos,
UI, etc.) de forma independiente.
● Microservicios con DDD: Cada microservicio puede ser diseñado y probado
individualmente utilizando DDD. Esto permite asegurar que cada microservicio
cumpla con sus respectivos modelos de dominio.
 Migración de una arquitectura a otra en Java
● Beneficios: Mejor rendimiento, escalabilidad, mantenibilidad, etc.
● Costos: Tiempo de desarrollo, posibles tiempos de inactividad, formación del
equipo.
● Métodos: Refactorización incremental, reescritura completa, replanteamiento.
● Ejemplo: Migrar un sistema de comercio electrónico monolítico a una arquitectura
de microservicios para mejorar la escalabilidad y el rendimiento.
Recordá:
● Revisar la Cartelera de Novedades.
● Hacer tus consultas en el Foro.

Todo en el Aula Virtual.

Muchas gracias por tu atención.
Nos vemos pronto