Patrones: Orientado a eventos / Provisión de eventos.

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.

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

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

Algo acerca de la implementacion

https://github.com/dotnet/docs/blob/master/docs/standard/microservices-architecture/multi-container-microservice-net-applications/integration-event-based-microservice-communications.md

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.

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?

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

Event-driven architecture style by MS

What is an Event-Driven Architecture? by AWS

Chapter 2. Event-Driven Architecture by Mark Richards

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!