Te doy la bienvenida a nuestro sitio web, en este sitio hallarás la respuesta que andabas buscando.
Solución:
Sospecho que está hablando de eventos de integración, no de eventos de dominio. En el segundo párrafo del artículo al que lo vinculó, se describe la diferencia, que básicamente es que los eventos de dominio se crean y consumen dentro del dominio (normalmente, pero no necesariamente, en el mismo espacio de direcciones), mientras que los eventos de integración unen diferentes dominios. Los eventos de dominio se pueden administrar mediante un servicio de mediador en proceso como Mediatr. Los eventos de integración se enviarían a algún servicio externo para su entrega.
También debe asegurarse de estar trabajando con eventos y no con mensajes. Los mensajes suelen ser de corta duración, llevan una carga útil de datos completa y solicitan que se realice alguna acción. Los eventos son de corta o larga duración, tienen una carga útil mínima y notifican a las partes interesadas que ya se ha realizado una acción.
La otra decisión que debe tomar es si desea una transmisión de eventos o simplemente una distribución. Una transmisión mantendrá los eventos durante un período prolongado de tiempo (días, semanas, meses), mientras que la distribución descartará el evento después de la entrega push a todos los suscriptores.
Aquí hay un buen artículo sobre las tres opciones de Azure disponibles: Event Grid, Event Hubs y Service Bus. Service Bus es para mensajería, Event Hub es para transmisiones de eventos y Event Grid es para distribución de eventos.
Los eventos son siempre eventos de dominio, ya que son activados por el dominio (generalmente por agregados). Son objetos de dominio nombrados según el lenguaje ubicuo. Es un evento de dominio sin importar si va a ser consumido por el mismo BC o por otro BC, o por los dos, no importa.
Dado un evento de dominio, si desea distribuirlo fuera de su BC para que otros BC puedan reaccionar ante él, utilice un mecanismo de sistema de mensajería de middleware (Azure Service Bus, RabbitMQ o lo que sea). El punto es que si desea que su BC reaccione al evento de dominio que desencadena, no tiene que usar el middleware, usa un mecanismo interno. Pero incluso en este caso, debería publicarlo también, ya que su BC quizás no sea el único interesado en el evento de dominio.
Lo que los documentos de Microsoft llaman evento de integración no es otro tipo de evento además de los eventos de dominio, es solo la estructura de datos del mensaje utilizado por el bus / cola de middleware, de modo que cuando publica un evento de dominio, lo traduce a un mensaje. Un evento de integración es una especie de evento de dominio DTO. Por otro lado, el consumidor BC toma el evento de integración y lo traduce en acciones a realizar en el modelo consumidor BC.
Vaughn Vernon explica un buen enfoque para administrar eventos de dominio en el libro rojo. Como resumen es el siguiente:
- A static despachador de eventos interno al BC, activa todos los eventos de dominio ocurridos en el BC.
- Si desea que el mismo BC reaccione a cualquier evento de dominio, suscriba un controlador para ello utilizando el static despachador.
- También suscribe un controlador que almacenará todos los eventos del dominio en una tienda de eventos (una tabla en la base de datos del BC).
- También debe implementar un reenviador de eventos que tome los eventos del dominio de la tienda de eventos y los publique en el sistema de mensajería midleware.
Aquí hay un enlace que me parece muy bueno implementando esta estrategia que les acabo de decir usando Azure Service Bus:
http://www.reflectivesoftware.com/2015/09/01/eventual-consistency-via-domain-events-and-azure-service-bus/
Espero eso ayude.
Hemos decidido basar nuestro sistema en Azure Service Bus con otros servicios de mensajería (Service Grid, Event Hubs) utilizados también, pero para tareas más limitadas.
ps nuestro contexto es el sistema ERP; donde la atención se centra en mensajes comerciales de alto valor (en lugar de velocidad, rendimiento como podría ser el caso de otros).
Los argumentos de este artículo de Mircosofts (por el arquitecto de Azure Service Bus) han influido mucho en nuestra elección. En particular lo siguiente:
Bus de servicio de Azure
Azure Service Bus es el servicio “Swiss Army Knife” para todas las demás tareas de mensajería genéricas. Si bien Azure Event Grid y Azure Event Hubs tienen un enfoque nítido en la recopilación y distribución de eventos a gran escala y con gran velocidad, un espacio de nombres de Azure Service Bus es un host para las colas que contienen trabajos de valor comercial crítico. Permite la creación de rutas para mensajes que necesitan viajar entre aplicaciones y módulos de aplicaciones. Es una plataforma sólida para el flujo de trabajo y el manejo de transacciones, y tiene instalaciones sólidas para lidiar con muchas condiciones de falla de aplicaciones.
Una venta registrada en una solución de punto de venta es tanto un registro financiero como un registro de seguimiento de inventario, y no un mero evento. Se registra en un libro mayor, que eventualmente se fusionará en un sistema de contabilidad centralizado, a menudo a través de varios puentes de integración, y la información no debe perderse en el camino. La información de ventas, posiblemente expresada como mensajes separados para realizar un seguimiento de los niveles de existencias en el punto de venta y en toda la región de ventas, se puede utilizar para iniciar pedidos de reabastecimiento automatizados con el estado del pedido que fluye de regreso al punto de venta.
Una fortaleza particular de Service Bus es también su función como puente entre elementos de soluciones y sistemas de nube híbrida que incluyen sistemas de sucursales o lugares de trabajo. Los sistemas que se encuentran “detrás del firewall”, están en itinerancia a través de redes u ocasionalmente están fuera de línea no pueden ser contactados directamente a través de mensajes “push”, pero requieren que los mensajes se envíen a una ubicación de recogida acordada desde donde el receptor designado pueda obtenerlos.
Las colas de Service Bus o las suscripciones a temas son ideales para este caso de uso, donde el núcleo de la aplicación empresarial reside en la nube o incluso en un centro de datos en el sitio, sucursales, sitios de trabajo o inquilinos de servicios repartidos por todo el mundo. Este modelo es particularmente popular entre los proveedores de SaaS en el cuidado de la salud, consultoría fiscal y legal, servicios de restaurante y venta minorista.
Composición
Debido a que a menudo es difícil trazar líneas nítidas entre los diversos casos de uso, los tres servicios también se pueden componer.
Por ejemplo, tanto Service Bus como Event Hub emitirán eventos en Event Grid que permitirán que las aplicaciones reaccionen a los cambios rápidamente, sin desperdiciar recursos en tiempo de inactividad.
https://azure.microsoft.com/sv-se/blog/events-data-points-and-messages-choosing-the-right-azure-messaging-service-for-your-data/
https://azure.microsoft.com/sv-se/blog/events-data-points-and-messages-choosing-the-right-azure-messaging-service-for-your-data/
Otro buen artículo (señalado por @ brad-irby) proporciona más detalles y una vista algo diferente: https://docs.microsoft.com/en-us/azure/event-grid/compare-messaging-services
También hemos agregado event sourcing funcionalidad; lo cual es muy importante en nuestro contexto.