Diapatching domain events though queue / messaging service

[mgcmartin2]

Hi I am currently implementing domain event dispatching though azure servicebus to make the domain event execution async and to ensure no lost events in case of errors.

The infrastructure layer implements a IQueueService that queues messages to Azure service bus when SubmitChanges are triggered on the DataContext.

the infrastructure layer also implements a Azure service bus consumer service that reads from the queue and triggers the eventhandlers with mediator. The event handlers are located in the application layer and infrastructure don’t know anything about them.

is this considered bad practice or wrong for the clean architecture example provided in this repository?

Edit: 09-02-2023

Just found out that what I am implementing is actually whats called integration events.
So a email that should be sent in case of a user registration could be an integration event to ensure it runs async and dosen't loss the event if an exception occurs (because its hold in a external queue system and can be reconsumed).

Now my question is how should I implement this properly into this arcitecture example?

My thoughts are doing it like Domain events with some methods on the entitites like AddIntegrationEvent()

But my thoughts are:

1. Could I modify the BaseEvent and add a property like IsIntegrationEvent that determines if its an domain event or integration event when creating new events that inherit the BaseEvent?

2. Should I create a new BaseIntegrationEvent or something like that?

3. Should the IntegrationEvents even live in the domain layer?

What do you think are the most proper solution?

[mrozov]

Your application layer may send an integration event as a part of your domain event processing logic. Directly or via the Outbox pattern.
But it should not influence your domain logic in any way. You may see an example in the eShopOnContainers.