Implementing Domain Events (DDD-CQRS) on Azure

Events are always domain events, as they are triggered by the domain (usually by aggregates). They are domain objects named according to the ubiquitous language. It is a domain event regardless whether it is going to be consumed by the same BC or by another BC, or by the two of them, it doesnt matter.

Given a domain event, if you want to spread it out of your BC so that other BCs could react to it, then you use a middleware messaging system mechanism (Azure Service Bus, RabbitMQ or whatever). The point is that if you want your BC to react to the domain event it triggers, you don't have to use the middleware, you use an internal mechanism. But even in this case, you should publish it out too, as your BC maybe not the only one interested in the domain event.

What Microsoft documents call integration event is not another kind of event besides the domain events, it is just the data structure of the message used by the middleware bus/queue, so that when you publish a domain event, you translate it to a message. An integration event is kindof a domain event DTO. On the other side, the consumer BC takes the integration event and translate it into actions to be done in the consumer BC model.

A good approach to manage domain events is explained by Vaughn Vernon in the red book. As a summary it is as follows:

• A static event dispatcher internal to the BC, triggers all the domain events ocurred on the BC.
• If you want the same BC to react to any domain event, you subscribe a handler for it using the static dispatcher.
• You also subscribe a handler that will store all the domain events in an event store (a table in the database of the BC).
• You have to implement also an event forwarder that takes the domain events from the event store and publish them in the midleware messaging system.

Here it's a link that seems very good implementing this strategy I've just told you using Azure Service Bus:

http://www.reflectivesoftware.com/2015/09/01/eventual-consistency-via-domain-events-and-azure-service-bus/

Hope it helps.

I suspect you are talking about integration events, not domain events. In the second paragraph of the article you linked to it describes the difference, which is basically that domain events are created and consumed within the domain (normally, but not necessarily, in the same address space), while integration events tie different domains together. Domain events can be managed using an in-process mediator service such as Mediatr. Integration events would be sent out to some external service for delivery.

You should also make sure you are working with events and not messages. Messages are typically short lived, carry a full data payload, and request some action to be performed. Events are short or long lived, carry a minimal payload, and notify interested parties that an action has already been performed.

The other decision you need to make is if you want an event stream or simply distribution. A stream will keep the events around for an extended period of time (days, weeks, months) whereas distribution will throw the event away after push-delivery to all subscribers.

Here is a good article on the three Azure options available – Event Grid, Event Hubs, and Service Bus. Service Bus is for messaging, Event Hub is for event streams, and Event Grid is for event distribution.