Want to master Clean Architecture? Go here: bit.ly/3PupkOJ Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt

Milan I am really looking forward to a full course from you, building an entire application with DDD, Rebus, RabbitMQ etc etc. I hope you will make one! Great video btw!

Speaking about trying to saving entity and domain events together, that is why I prefer using event sourcing :) you deal only with domain events and rebuild entities based on them.

Clean and simple implementation, thanks for sharing with us.

I'm really liking your videos. Always clear and concise.

Hey Milan, really nice video. I'm looking forward for this new robust impl of the outbox pattern. Thanks for making such an awesome content, free.

You are the best man ... !! learning a lot from this collection of videos !! I feel my self like an expert in DDD ... hahaha

Looking forward to an indepth Outbox Pattern video. ❤

Hi Milan! Great video. Is there any video in which you talk about integration events? Thanks for the content.

TQ Milan^^ 14:01

After watching couple times, im still left with impression that nothing changed from start to end, we are still raising event after we saved changes to the DB except at start, specific event was raised in domain layer probably scattered and at end all events are raised by iterating events in the persistence/infrastructure layer. at both times we would throw any exception in the events back to the UI/calling layer. Am i missing something? Effectively the title of the video is achieved in a way but the drawback still exist. i think the drawback is true for any in memory event bus.

Lesser of two evils Indeed, i prefer the approach that is after and as some clean up

Question. I have a CreateSomethingAHandler and during this handler, my domain has raised an event. So I will have AEventHandler. During AEventHandler, can this AEvent raise another Event? like a chair event? Does it sound like bad practice? CreateHandler -> Domain raise an event-> EventHandler-> Domain can Raise another EventHandler?

Hi, Milan! This is clear for use cases where you invoke methods on the aggregate root, such as create() or addItem(), where you can publish the corresponding event inside the entity producing it, but how would you approach an OrderDeletedEvent? Would you need to pass through a delete() method or something alike?

Really like your content and views on real world architectural challenges. Isn”t this specific approach creating a dependency on MediatR in your domain model? I consider this a framework dependency that I would avoid.

Hi Milan, perfect timing; I was just introducing DomainEvents to an otherwise Clean Architecture yesterday. Pretty much as you present it. However, a consideration: One of my events is change of State and I was debating with myself whether I should have a StateChangedDomainEvent or multiple like StateChangedToAuthorized, StateChangedToTerminated etc. I guess "it depends", but do you have any thoughts you'd like to share?

Create your DomainEvent implementing INotification makes the Domain tightly coupled to MediatR and any changes to MediatR affect your domain and I think it is not a good practice but I could be wrong

Very clear video as always, thank you! Generally speaking would it be better to not pass the cancellation token to _publisher.Publish ? By that I mean if the system has got as far as saving the changes to the database we do not want to allow it to back out of publishing the domain events.

thank you for a nice video, I have a question regarding using the MediatR in the domain layer. i kknow that that domain layer should not have any integration with other libraries, can you please explain why in your case you use an external library ? I would appreciate your answer.

Btw water to ask, do you use domain events to communicate between aggregates much?

I am not really a fan of publishing integration-events inside domain-event handlers. I think it's better to have a clear separation between the domain- and integration-events. Domain-events are handled as a part of the transactions and integration-events are published after the transaction has completed. It still does not fix the problem where publishing the integration-events fails but you could always switch to using outbox pattern. How about this? // Application layer class DomainEventHandler { public DomainEventHandler(DbContext dbContext) { ... } public Handle(SomeDomainEvent event) { var someEntity = this._dbContext.GetSomeEntityBy(event.Data); someEntity.Update(event.Data2); someEntity.RaiseIntegrationEvent(new SomeIntegrationEvent()); } } And inside SaveChanges() publishDomainEvents(); base.SaveChanges(); publishIntegrationEvents(); Domain-events are published inside domain layer and integration-events are published in the application layer. Domain-events handlers can be a part of the transaction and integration-events are published after the transaction has completed.

Great video, thanks! Will there be more videos with the development of the E-shop web api? And will you add any new entities to the project? Product cart for example

Can you please milan make a video about Threading , async and await and Parallel and multi-threading if you have time. And Thanks for all your effort

Another question please what do you mean by 'Atomic' in the latest approach, Do you mean that we will either persist the business logic and the event in the db or if there is any problem then we will rollback the business logic and also the event ?

Hi Milan! I have one question. When we are removing a line item, this is done by a function inside the aggregate root Order. So we can call the function Raise passing the LineItemRemovedDomainEvent. How would be the approach to an aggregate root deletion (ex: Order)? We would have to expose the Raise function and call it from the handler? Thanks.

Hello, how can i publish domain events if i have separate domain and database models?

I love your channel, it is extremely useful. I have a question. How it is possible to persist an event by ef core change tracking that was raised in the rich model while the snapshot pattern is used to map the rich model to a model that is supposed to be persisted into the database?

I use id value objects for my domain entities. So I have something like public sealed class domainEntityName : Entity { ... }. My domainEntityNameId inherits from public sealed class UserId : EntityId { ... }. At min 10:41, where you grab the domain events from the changetracker, would I put something like ChangeTracker.Entries() ? The reason I ask is because when I try to obtain my domain events, I get zero count.

Why is domain event publishing being implemented in ApplicationDbContext? Shouldn't this be implemented in UnitOfWork (of course, if you are using the pattern)?

Hi Milan, Thx again for nice introduction to domain events! 1. Is implementation of the Application's OrderCreatedEvent.cs: internal record OrderCreatedEvent(Guid Id); or we need something more? 2. May I ask for the name the VS theme that you're using. Very simple and nice one.

So..... Everything is possible to implement without MediatR. And it will have exactly the same behavior but without additional framework. Please correct me if I'm wrong.

Milan, can we store saga in MS-SQL apart from StoreInPostgres?

Hi, Milan. I want to ask you to create a video about Cancellation token. I know what is it, but I'm interesting in situation there I have to implement the cancellation callback for production. This thing possibly the most frequently used element and a lot of developers actually don't understand how to use it. (As am I actually😅). I'm coming to read.

Hii 🖐 I watched your video on creating domain events, and I found it very informative. However, I noticed that your implementation seems to violate the principle that the domain should not depend on any dependencies.

Is the code available to download and practice?

Why not only trigger the event when a save was succesfull? Then you would only communicate the persistant state.

what if i have domain events that change state of entities how this changes will save in database ? i think can solve this : await base.SaveChngesAsync(); // publish events await base.SaveChangesAsync();

like Homer would say, yesssss but nottt, it didn't like what i saw, why do you use context database and you don't create a repository o service to use data layer, you have datacontext on each handler, ummmm it looks bad