How to Use the Domain Event Pattern | DDD, Clean Architecture, .NET 6

The Domain Event pattern is a very useful way to offload important work to the background. In this video, I'm going to show you how to use domain events to improve the reliability of your code. Domain events can only be raised by the aggregate roots in our Domain model. After a domain event is raised, it is handled in the corresponding domain event handler.

Join my weekly .NET newsletter:

Subscribe for more:

Chapters
0:00 What is a Domain event
1:25 Creating a Domain event
2:38 Raising Domain events from AggregateRoot
4:28 Implementing a Domain event handler
8:38 How to publish Domain Events

[AlbertBalbastreMorte]

Oh, that makes sense. I just realised I've been using this in my last job. The typical sending of email would be handled by an async job. We just didn't call it domain event, but it was functionally the same. I understand this decouples the primary action and the waves that it may make on the pond, which can be interesting.

[salmanzafar-jriu]

outbox pattern is the key to including domain events saved in a database with the transaction and introducing a background job to consume them

[rezvlt]

Following these videos. Hopefully they'll take me from junior to mid in the coming months. I'll let you know how I get on Milan

[ugochukwuumerie]

Awesome! The wait is over. wonderful series. Would love to see a separate video of the outbox pattern. Thanks.

[daedwill]

Great video. Just remember to inject those services into the constructor of the MediatR event handler classes. In the video it's just declared as private fields.

[fernandocalmet]

I was waiting for this chapter, thank you very much Milan! This series is great!

[VoroninPavel]

Nice video, good structure. Some IMHO-comments:

- DomainEvent postfix is probably excessive here simply because of the specific naming pattern Noun + Past Participle.
- As to Outbox pattern, I'd suggest having two types of handlers: (a) working within main transaction and (b) those which handle outboxed events (usually requires external activities like sending emails. In most cases such handlers belong to app layer). However, in some cases you'd need to ensure cross-aggregate invariants and let handler throw, so transaction is rolled back. This gives you the opportunity for so to say post-action validation. Action -> Event -> Handlers validate. The pro of this approach is ease of extending invariants checks, and it becomes impossible to forget about the check. Con: it's hidden in handlers, and not that obvious.

[Yosso]

Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?

[manya.korolevskaya]

Hi Milan!
Thank you for the video! Can't wait when the next chapter about sending events is going to be published.

[AboutCleanCode]

Considering Clean Architecture I think it is not a good idea to make your domain layer depending on MediatR library. Adapting to breaking changes of that library or migrating to another implementation of this pattern later on would be quite painful. At least in bigger projects I would recommend defining own interfaces for notifications in the domain and then have adapters in the adapters/infrastructure layer to the actual notification implementation library.

[donnyroufs]

Great video. It's funny that nowadays everyone just violates the fact that the core (domain + app) shouldn't have any external dependencies. Going to be fun when something happens to MediatR

[WesamWassouf-zqgs]

thank you very much Milan! This series is great!

[acodersjourney]

Hello, thank you for this video. In the video, you mentioned outbox pattern. I just wanted to know if you have created any videos about this pattern. Keep up the good work.

[EMWMIKE]

amazing video, you are such a good instructor

[majormartintibor]

Good video. Yes I think I will use it.

[belsheikh]

5:21 Is it ok to reference mediatR from the domain? I thought this breaks the clean architecture dependency. Or maybe my understanding is wrong.

[wvanlosser]

And yet again a very informative video! Keep up the good work!

[hosseinnazari]

hi, thanks for great content, ithink for domain event we do not needoutbox pattern we can just override dbcontext saveChanges or uow saveChanges metrhod to raise events after or before actual db saveChanges method but for integrationEvent we need to use outbox pattern to make sure our events published at least one time
it would be wonderful if you give your idea about my comment
again thanks for great content

[charleslord]

Great video! What would you do for events which correspond to the creation of an Aggregate Root entity. (so something like a GatheringCreated domain event) I see problems with putting the event into the DomainEvents List in the constructor as an event would be registered every time an object was created, not just when an entity itself was actually created and persisted for the first time. Do you have any suggestions on how to handle this?

[dilipmevada]

Hi Milan, Can you please share any real-time example where we can use this pattern?