Implementing Domain Events (DDD-CQRS) on Azure

Question

Microsoft docs provides an article on "Domain events: design and implementation" for DDD & CSRS.

How could domain events be implemented on Azure. In particular which Azure services are suitable, and how do you combine them.

Relatively little has been written on this topic so far. This presentation seems good. In part it talks about possible implementations; e.g. Azure Functions vs Azure Logic Apps; and Azure Service Bus vs Azure Event Grid.

Answer 1

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.

Answer 2

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.

Answer 3

We have decided to base our system around Azure Service Bus with other messaging services (Service Grid, Event Hubs) used as well but for narrower tasks.

p.s. our context is ERP system; where the focus is on business messages of high value (rather than speed, throughput as might be the case for others).

Arguments in this Mircosofts's article (by Architect of Azure Service Bus) has strongly influence our choice. In particular the following:

Azure Service Bus

Azure Service Bus is the “Swiss Army Knife” service for all other generic messaging tasks. While Azure Event Grid and Azure Event Hubs have a razor-sharp focus on the collection and distribution of events at great scale, and with great velocity, an Azure Service Bus namespace is a host for queues holding jobs of critical business value. It allows for the creation of routes for messages that need to travel between applications and application modules. It is a solid platform for workflow and transaction handling and has robust facilities for dealing with many application fault conditions.

A sale recorded in a point-of-sale solution is both a financial record and an inventory tracking record, and not a mere event. It’s recorded in a ledger, which will eventually be merged into a centralized accounting system, often via several integration bridges, and the information must not be lost on the way. The sales information, possibly expressed as separate messages to keep track of the stock levels at the point of sale, and across the sales region, may be used to initiate automated resupply orders with order status flowing back to the point of sale.

A particular strength of Service Bus is also its function as a bridge between elements of hybrid cloud solutions and systems that include branch-office or work-site systems. Systems that sit “behind the firewall”, are roaming across networks, or are occasionally offline can’t be reached directly via “push” messaging, but require messages to be sent to an agreed pickup location from where the designated receiver can obtain them.

Service Bus queues or topic subscriptions are ideal for this use-case, where the core of the business application lives in the cloud or even an on-site datacenter, branch-offices, work-sites, or service tenants spread across the world. This model is particularly popular with SaaS providers in health care, tax and legal consulting, restaurant services, and retail.

Composition

Because it’s often difficult to draw sharp lines between the various use-cases, the three services can also be composed.

e.g. both Service Bus and Event Hub will emit events into Event Grid that will allow applications to react to changes quickly, while not wasting resources on idle time

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/

Another good article (pointed out by @brad-irby) provides more details and somewhat different view: https://learn.microsoft.com/en-us/azure/event-grid/compare-messaging-services

We have also added event sourcing functionality; which is very important in our context.