Introducción al curso

1

Diseño y Documentación de Arquitectura de Software

Atributos de calidad

2

Atributos de Calidad en Sistemas: Definición y Medición

3

Idoneidad Funcional: Completitud, Exactitud y Pertinencia

4

Eficiencia de Ejecución en Sistemas Informáticos

5

Compatibilidad en Sistemas: Interoperabilidad y Coexistencia

6

Subcaracterísticas de Usabilidad en Desarrollo de Software

7

Confiabilidad de Sistemas: Madurez, Disponibilidad, Resiliencia y Recuperación

8

Seguridad de Usuarios en Desarrollo de Software

9

Subcaracterísticas de Mantenibilidad en Sistemas de Software

10

Medición de Adaptabilidad en Sistemas de Software

11

Relación y Tensión entre Atributos de Calidad en Sistemas de Software

12

Atributos de Calidad en Arquitectura de Software

Patrones de arquitectura

13

Patrones de Arquitectura Monolítica y Distribuida

14

Modelo Vista Controlador: Separación de Responsabilidades en Aplicaciones

15

Arquitectura de Capas: Diseño y Comunicación entre Niveles

16

Patrones de Arquitectura Orientada a Eventos y Event Sourcing

17

Patrón de Arquitectura MicroKernel y su Implementación en IDEs

18

Arquitectura "Comparte Nada": Optimización y Procesamiento de Datos

19

Patrón de Microservicios en Arquitectura de Software

20

Patrón CQRS para Separación de Consultas y Comandos

21

Arquitectura Hexagonal: Diseño y Aplicación Práctica

22

Diseño Orientado al Dominio: Conceptos y Aplicaciones Prácticas

23

Patrones de Arquitectura para Aplicaciones Escalables y Modulares

24

Patrones de Arquitectura en Proyectos de Crecimiento Empresarial

Diseño de una arquitectura

25

Diseño de Arquitecturas a Medida: Herramientas y Estrategias

26

Tipos de Conectores en Arquitectura de Software

27

Conectores Asíncronos y Sincrónicos: Implementación y Uso Práctico

28

Diferencias entre Enrutadores y Difusores en Comunicación de Mensajes

29

Conexión de Productores y Consumidores con Colas de Mensajes

30

Framework de Diseño Orientado a Atributos: Escenarios y Tácticas

31

Tácticas para Mejorar la Disponibilidad de Sistemas

32

Tácticas para Mejorar la Disponibilidad del Sistema

33

Tácticas para Mejorar la Mantenibilidad del Software

34

Prevención de Efectos Dominó en Mantenibilidad de Software

35

Estrategias para Mejorar la Eficiencia de Ejecución en Sistemas

36

Tácticas de Seguridad Informática para Detectar, Resistir y Recuperarse de Ataques

37

Estrategias para Mejorar la Capacidad de Prueba de Software

38

Tácticas de Usabilidad en Diseño de Interfaces de Usuario

39

Validación de Arquitectura con ATAM y Métricas de Calidad

40

Diseño de Arquitectura para Startups y Empresas Escalables

Modelado y documentación de arquitectura

41

Documentación Efectiva de Arquitectura de Software

42

Sincronización de Modelos de Arquitectura y Código Fuente

43

Evaluación de Atributos de Calidad en Arquitectura de Software

No tienes acceso a esta clase

¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera

Patrones de Arquitectura Orientada a Eventos y Event Sourcing

16/43
Recursos

¿Qué es la arquitectura orientada a eventos?

La arquitectura orientada a eventos, o event-driven architecture, es un enfoque que intercambia datos mediante eventos. Este sistema permite que componentes, como microservicios, se comuniquen a través de un bus de eventos, eliminando el acoplamiento directo entre ellos. Este método es ideal para arquitecturas de microservicios, donde cada componente publica eventos y otros componentes suscritos los consumen. Así, se facilita la independencia, el despliegue y el mantenimiento de cada módulo.

¿Cómo funciona en la práctica?

Imaginemos un caso práctico de arquitectura orientada a eventos. Se pueden identificar dos roles: productores y consumidores de eventos. Por ejemplo:

  • Una API puede ser productora de eventos al momento de recibir una solicitud para escribir datos.
  • Este evento se publica en el bus de eventos y otros módulos, como ventas o clientes, pueden consumirlo para actualizar sus bases de datos.

Asimismo, un proceso de importación de archivos puede ir publicando eventos con el contenido del archivo, los cuales son consumidos por servicios suscritos a esos eventos.

¿Cuáles son los retos de esta arquitectura?

Este enfoque presenta desafíos, como:

  • Consistencia eventual: La arquitectura orientada a eventos suele ser consistente de manera eventual. No garantiza que los datos estén disponibles inmediatamente hasta que los eventos se distribuyen completamente.
  • Pruebas complejas: La dificultad de pruebas tipo end-to-end aumenta, dado que es necesario utilizar el bus de eventos para coordinar la interacción entre módulos.

¿Qué es Event Sourcing?

El Event Sourcing es una variación de arquitectura orientada a eventos donde, en vez de mantener el estado actual de un sistema en una base de datos, se almacenan todos los eventos que lo llevaron a su estado actual. Esto permite entender el estado no solo en el presente, sino a lo largo de todo su ciclo de vida.

Ventajas del Event Sourcing

El Event Sourcing ofrece numerosas ventajas, tales como:

  • Auditoría: Proporciona un completo log de eventos para auditorías.
  • Depuración y recuperación: Ayuda en la depuración y recuperación ante ataques, ya que permite identificar cómo el sistema llegó a un determinado estado.
  • Flexibilidad: Puede reconstruir el estado actual en cualquier momento utilizando el historial de eventos.

Desafíos al implementar Event Sourcing

Implementar Event Sourcing implica ciertos retos:

  • Rendimiento: A medida que los eventos se acumulan, determinar el estado actual puede ser más lento. Algunas soluciones implementan patrones de diseño para obtener estados intermedios y optimizar las consultas.
  • Recursos: Almacenar todos los eventos demanda un uso considerable de recursos del sistema.

Un ejemplo sería una aplicación bancaria que, en lugar de almacenar el estado actual de las cuentas, guarda las transacciones como eventos. Así, es posible validar transacciones y visualizar el historial de operaciones, asegurando una gestión más efectiva de recursos y acciones.

Consejos prácticos sobre arquitectura orientada a eventos

  1. Evalúa tu necesidad: No todos los proyectos requieren un enfoque basado en eventos. Analiza si la independencia y descentralización de módulos benefician a tu arquitectura antes de implementarla.
  2. Optimización: Considera el uso de patrones de diseño que ayuden a mejorar la eficiencia del sistema, especialmente en el manejo de grandes volúmenes de eventos.
  3. Capacitación continua: La tecnología evoluciona rápidamente, por lo que es esencial seguir actualizándote sobre nuevas prácticas y herramientas que optimicen arquitecturas basadas en eventos.

En conclusión, la arquitectura orientada a eventos es una herramienta poderosa pero también compleja. Tomar decisiones informadas sobre su implementación logrará un sistema robusto y eficiente que cumpla con las crecientes demandas tecnológicas.

Aportes 21

Preguntas 2

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad?

Apuntes:

Orientado a eventos / Provisión de eventos

Orientado a eventos. Trata sobre cómo conectar componentes a través de eventos. Cada componente publica eventos a un bus de eventos común y los componentes interesados a estos eventos pueden estar suscritos y luego responder al respecto. No hay otra forma de comunicación, el bus de eventos pasa ser el método principal de comunicación entre componentes. Algo complejo es saber si una acción que hicimos tuvo el resultado que esperábamos, en general suelen ser eventualmente consistentes, lo que significa que cuando hacemos una escritura el sistema no nos garantiza que va a estar disponible hasta que ese evento no se distribuya en todas las partes que lo necesita.

Provisión de eventos. En vez de que nuestra aplicación tenga el estado actual del sitio, podríamos tener solamente guardados los eventos que nos importan.

###Patrones: Orientado a eventos
Trata de conectar componentes a través de eventos. Cada componente puede estar subscrito (conectado) a un Bus de Eventos y el componente que este interesado en dicho evento puede responder. El bus de eventos pasa a ser el método principal de componentes.


Es difícil de testear porque hay que conectar e bus de eventos con los diferentes módulos, esto hace que sea mas complejo las pruebas end to end.


<h4>Provisión de eventos.</h4>

Se leen de forma secuencial para conocer el estado actual y a través del log de eventos, solo guarda los eventos que importan.

Siempre se debe estudiar el caso de uso y evaluar si es el adecuado para el desarrollo de mi solución, ya que cada patron tiene sus pros y contras

En el caso del patron orientado a eventos:
Pro: permite desligar un sistema distribuido mediante el bus, logrando asi mayor capacidad a la hora de escalar mi sistema distribuido.
Contra: Mayor dificultad a la hora de hacer pruebas end to end.
Contra: El mismo bus de eventos podria ser un punto de falla. Se debe contar con buenas capacidades para soportar el nivel de transaccionalidad del bus de eventos.

Patrón de arquitectura Orientado a Eventos
Conecta componentes a través de eventos.
Cada componente publica eventos a un bus de eventos común y los componentes interesados en estos eventos pueden estar subscritos y luego responder al respecto.
En esta arquitectura, el bus de eventos pasa a ser el método principal de comunicación entre componentes.

Caso especifico de uso de eventos.
Arquitectura Provisión de eventos.
Consiste en que la App tenga el estado actual del sitio, solo guardar los eventos que nos importan.
Se leen en forma secuencial para saber el estado actual.

Con esta arquitectura se puede saber el estado en cualquier momento de su ciclo de vida

Event Sourcing by Marting Fowler: https://martinfowler.com/eaaDev/EventSourcing.html

Blockchain! Eso sería event sourcing, creo.

¿EventSourcing tiene algo que ver con BlockChain o solo se parecen?

No me queda claro algunas cosas en especifico, Si tengo una api de ingreso de eventos de qué manera puede consumir algún evento? ¿Es decir que si tengo una API de ingreso de eventos los demás componentes van a producir eventos únicamente a la hora de actuar con relación al evento que se produjo en la API? Sí no es el caso cuál es la diferencia entre un evento producido por la API de ingreso de eventos y un evento producido por otro componente? ¿Podrían darme un ejemplo? Gracias
Centralizar todos los eventos en un solo componente, como una API de ingreso de eventos, puede ser una práctica válida en ciertos contextos. Sin embargo, puede llevar a un acoplamiento excesivo y convertirse en un único punto de fallo. Es recomendable seguir principios de diseño que promuevan la descentralización y el desacoplamiento, permitiendo que múltiples productores de eventos interactúen con un bus de eventos. Esto mejora la escalabilidad y la mantenibilidad del sistema. Considera el contexto de tu aplicación y si la centralización se ajusta a los requerimientos del negocio.
**Event Sourcing: Concepto y Casos de Uso** * Event Sourcing es una técnica de diseño de software donde los cambios en el estado de una aplicación se capturan como una secuencia de eventos. Estos eventos se almacenan y pueden ser consultados o utilizados para reconstruir estados anteriores de la aplicación. * **Casos de Uso**: * **Sistemas de Control de Versiones**: Utilizan consultas temporales y reconstrucción de estados pasados. * **Aplicaciones Empresariales**: Aunque menos comunes, algunas aplicaciones empresariales implementan Event Sourcing para partes específicas de su funcionalidad. * **Ventajas**: * **Auditoría y Depuración**: Proporciona un registro completo de cambios para auditorías y facilita la depuración al permitir la reproducción de eventos en ambientes de prueba. * **Retroactividad y Reversibilidad**: Permite ajustar estados pasados y revertir eventos si es necesario. * **Desventajas**: * **Complejidad con Sistemas Externos**: Manejar interacciones con sistemas que no utilizan Event Sourcing puede ser complicado, especialmente para actualizaciones y consultas externas. * **Rendimiento**: Calcular estados solicitados desde un estado inicial en blanco puede ser un proceso lento si hay muchos eventos. Event Sourcing es una técnica poderosa con aplicaciones específicas, especialmente útil para sistemas que requieren un alto nivel de trazabilidad y capacidad de reconstruir estados pasados. Sin embargo, su implementación puede añadir complejidad y desafíos de rendimiento que deben ser considerados cuidadosamente. [Event Sourcing (martinfowler.com)](https://martinfowler.com/eaaDev/EventSourcing.html)
**Event Sourcing: Concepto y Casos de Uso** * [**Definición**: Event Sourcing es una técnica de diseño de software donde los cambios en el estado de una aplicación se capturan como una secuencia de eventos](https://edgeservices.bing.com/edgesvc/chat?udsframed=1\&form=SHORUN\&clientscopes=chat,noheader,udsedgeshop,channelstable,wincopilot,ntpquery,devtoolsapi,udsinwin11,udsdlpconsent,udsfrontload,cspgrd,\&shellsig=a3c86a9a9b12b5d03c13eb5b3a9b6ec9612aee64\&setlang=es\&darkschemeovr=1#sjevt%7CDiscover.Chat.SydneyClickPageCitation%7Cadpclick%7C0%7C77189148-cf36-47bc-8b1f-d6c60365e16b). Estos eventos se almacenan y pueden ser consultados o utilizados para reconstruir estados anteriores de la aplicación. * **Casos de Uso**: * **Sistemas de Control de Versiones**: Utilizan consultas temporales y reconstrucción de estados pasados. * **Aplicaciones Empresariales**: Aunque menos comunes, algunas aplicaciones empresariales implementan Event Sourcing para partes específicas de su funcionalidad. * **Ventajas**: * **Auditoría y Depuración**: Proporciona un registro completo de cambios para auditorías y facilita la depuración al permitir la reproducción de eventos en ambientes de prueba. * **Retroactividad y Reversibilidad**: Permite ajustar estados pasados y revertir eventos si es necesario. * **Desventajas**: * **Complejidad con Sistemas Externos**: Manejar interacciones con sistemas que no utilizan Event Sourcing puede ser complicado, especialmente para actualizaciones y consultas externas. * **Rendimiento**: Calcular estados solicitados desde un estado inicial en blanco puede ser un proceso lento si hay muchos eventos. Event Sourcing es una técnica poderosa con aplicaciones específicas, especialmente útil para sistemas que requieren un alto nivel de trazabilidad y capacidad de reconstruir estados pasados. Sin embargo, su implementación puede añadir complejidad y desafíos de rendimiento que deben ser considerados cuidadosamente. [Event Sourcing (martinfowler.com)](https://martinfowler.com/eaaDev/EventSourcing.html)

Patron orientado a eventos: este patron trata de conectar componentes a través de eventos. Cada componente puede estar suscrito a un Bus de Eventos y el componente que este interesado en dicho evento puede responder. El método principal pasa a ser el Bus de eventos.

  • Ventajas: Escalabilidad, despliegue, Flexibilidad.

  • Desventajas: Tests, desarrollo.

Me gusto mucho la información que encontré en esta fuente: https://reactiveprogramming.io/blog/es/estilos-arquitectonicos/eda

Orientado a eventos / Provisión de eventos
Orientado a eventos. Trata sobre cómo conectar componentes a través de eventos. Cada componente publica eventos a un bus de eventos común y los componentes interesados a estos eventos pueden estar suscritos y luego responder al respecto. No hay otra forma de comunicación, el bus de eventos pasa ser el método principal de comunicación entre componentes. Algo complejo es saber si una acción que hicimos tuvo el resultado que esperábamos, en general suelen ser eventualmente consistentes, lo que significa que cuando hacemos una escritura el sistema no nos garantiza que va a estar disponible hasta que ese evento no se distribuya en todas las partes que lo necesita.
Provisión de eventos. En vez de que nuestra aplicación tenga el estado actual del sitio, podríamos tener solamente guardados los eventos que nos importan.

Este patrón trata principalmente con eventos y tiene 4 componentes principales; fuente de evento , escucha de evento , canal y bus de evento . Las fuentes publican mensajes en canales particulares en un bus de eventos. Los oyentes se suscriben a canales particulares. Los oyentes son notificados de los mensajes que se publican en un canal al que se han suscrito anteriormente.

Recordar que todo patrón de diseño va a tener beneficios y va a tener consecuencias, por eso hay que analizar cuál es el mejor o el patrón que más beneficios tiene en la solución del problema!