Get the source code for this video for FREE → the-dotnet-weekly.ck.page/domain-events Want to master Clean Architecture? Go here: bit.ly/3PupkOJ Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
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.
@@MilanJovanovicTech Isn't the point of domain and integration events to have them decoupled from the action that triggered them? Is there anything else I'm missing?
@@MilanJovanovicTech Not yet in production software, but i'm trying to implement it in a personal project. This series really helps clarifying certain topics.
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.
@@paulbarton2280 I usually use Quartz for that, since i can leverage the native HostedService in ASP.NET UoW - Nothing special to be honest, just the DbContext. Maybe you had something more specific in mind? 🤔
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?
Yes, I had the same problem! This is why I resort to using a static factory pattern. Inside of that method you can call the ctor and raise the domain event. And you won't run into that issue
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.
Hi Pavel, I appreciate the comment! - It's just a personal preference, I add the postfix to commands/queries/events by convention. I also use it because when I "Ctrl + T" in VS I can quickly navigate to the domain event and handler. - That's a very interesting suggestion. I'm curious what is the benefit over validating the invariants inside of the command handler directly? We would still be inside of the main transaction, but the behavior would be explicit.
@@MilanJovanovicTech I think it depends on whether several commands can lead to the same event. Also, in Event Sourcing, events are the source of the state, but in our project, for example, we inverted the sequence: we call aggregate methods to change the state and events get published by aggregate itself.
Nice video Milan. Thanks! I working on a DDD with CQRS, event store, Onion Architecture and Azure service bus, project. i have a question based on your example.Wouldn't be better to have a folder in Application project named EventHandlers, and there to declare an event handler per entity, like InvitationEventHandler, and inside of this class we can handle all the events related to it. Or maybe other events related to other entities but which somehow can change the Invitation state or properties? Like this we can avoid having an event handler per event, we can end up in having a lot of events and of course a lot of event handlers. Or is this a best practice?
Hello thx for amazing videos. I have question, should domain events be stored in agreggate in db, as a list what happened with aggregate like history? If yes how to deal with different structure of different events?
Hi Milan i see you from Argentina, thanks you very much. How publish the domainEvent? its ok if i publish the domain event when the entity saved overriding the metod SaveChange of ef in this case or is better apply the outbox pattern?
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.
Consider Clean Architecture - I would agree with you. But it's important that we are *pragmatic* as engineers. My thought: - I don't think MediatR will introduce a breaking change (ever probably) - Why would I switch implementation if this one gets the job done? - Even switching would come down to using a different interface most likely - As for rolling your implementation, I do think it's not too complicated to implement, but is it really worth the effort?
@@MilanJovanovicTech Well, i do understand your thoughts and i like to be pragmatic as well - so i would agree with you definitively for smaller projects. On the other hand: would it really be "measurable effort" of introducing own interfaces and some adapters right from the beginning? i never used MediatR on my own but wouldn't we talk about a few lines of code? And the increase in complexity (because of the indirection) would be minimal compared to the benefit of avoiding "broken window effect" right from the beginning. i know this is rather philosophical discussion but it is good to have such discussions among software engineers ;-)
@@AboutCleanCode This problem is always there. It is important to be pragmatic and know where to draw the line. Architecture principles are there to guide us and prevent us from getting into a situation where it is difficult to maintain code or have agility in code. However, we should not be too dogmatic that we rather land in the same situation trying to implement it
That's why and many other don't like the Clean Architecture as a concept of separating the code. With more classic approach when using repositories + services/cqrs + controllers/endpoints you can get the job done without some really stupid restrictions. In the microservice world IMediatr is a wonderful thing which can hide inside other details for publishing events, like for example: publish an even using MediatR and after that put the event into Redis or some type of message queue. Will I don't like the clean architecture I like the DDD. Each of them can live really well without each other
Are there tools for visualizing the resultant choreographed workflow? Flexibility is nice but it adds a ton of complexity when you need to know how its coupled to answer 'simple' business questions.
No there aren't any tools, at least to my knowledge. I agree that the flexibility is increased at the cost of complexity. But I find it well worth it in the long run.
Hey Milan, I really enjoy your content and have a few questions: Would you recommend seperating domain objects and ef core entities fully? If not, why? In the context of event sourcing and the likes, would you treat the relational query database like the email service and just notify it through domain events? Is that a stupid idea? I've played around with that idea a few times but found it pretty hard to implement in a smooth way. Thanks!
- My Domain projects are my EF Entities, at the same time. I don't see much benefit in creating additional classes for EF Entities. - Event sourcing can be quite difficult to manage on your own. But you could probably get by with raising Domain Events for every single change in the system. And then on the query side, processing those events and filling up your query model.
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.
What happens if I need to execute some business logic in the handler, for example to communicate the information that something has happened in my domain A and I need to do something in response in my domain B and a business error occurs? How can I roolback what has been done in domain A (let's say we're complement async) to keep data consistency?
Hey mate, How would you go about firing a domain event for entity deletion? Should I add a method to then entity such as "FlagForDeletion()" that raises an event that gets fired on save changes when the entity is removed from the repository?
Hi, Milan thanks again for this rich content, I'm new to DDD and a bit confused my question is why we don't use events in c# with the pub/sub model for the implementation or it's not not a good approach, Thanks!?
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
Hello Milan, I have customer in my domain. Can i create event as CustomerRegistrationComplated event or should be CustomerCreatedEvent which one correct ? also when user sign-in I publishing UserSignedIn event, is it domain event? Should we seprate that as busines events
one question, what about if Emails service is another hosted application and has to send emails asynchronously would you prefer to raise a domain Event? or you will go for an integration event?
Hi Milan, if the business states "when an invite is accepted, send them an email". Now with the event we are leaking domain knowledge into the application layer as the application / infrastructure layer now decides what exactly we are doing with the event. We could send a sms instead an email and miss the business requirement. What are your thoughts on this?
Actually, use cases of the business are defined and controlled by application (layer; where commands and command handlers are defined) so we’re all good here. So if the use case changes from sending an email to sending SMS, you would update the use case itself. Rules regarding how gathering/invitations relation work from the business perspective hasn’t changed, so no need to touch the domain.
Great video. very helpful. I was waiting until de very end to check if you would talk about event concurrency when for example a consumer receives 2 events to an updated entity since it's dificult to garantee event processing order in a micro services enviorment. What are your thoughts about this? Maybe it's an idea for a future video :)
I also saw that video but the issue i was talking about was let's say entity A has an integer that has initial value 0 and receives an update to change it to 1 and at the same theres is another update that changes it to 2. Both update events are valid and are published sucessefully but depending on the order they arrive to the consumer there can be incosistent reactions. again this in a micro service enviorment
Hey Milan, it's a great video! I just wanna ask a question, would not it be better to raise the domain event (for InvitationAcceptedDomainEvent) in the Accept method of the Invitation class? Because we need to call the Accept method to accept the invitation and then need to raise a domain event related to that. (in every place that needs this logic)
In our case, only the AggregateRoot can raise Domain Events. Invitation is an Entity, in the current design, so it can't raise Domain Events. If we changed our design so that Invitation is also an AggregateRoot, that would be perfectly fine.
@@MartinoBordin Yes. You want you AggregateRoot to control your entire aggregate. So any modifications to the objects inside of the aggregate will flow through the AggregateRoot. Which is why it makes more sense to me to only allow the AggregateRoot to raise Domain Events. Of course, if you feel this is too constraining - you can move the implementation to the Entity perhaps.
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
What are the chances of that happening, Donny? Sometimes it's better to be pragmatic about it. Worst case scenario, we implement our own IDomainEvent/IDomainEventHandler mechanism. What should that be - a few hours of work when (if ever) needed?
I’m on the same boat as Milan. The MediatR handler infrastructure is great fit for a domain event handler, no need to make your own until proven necessary. Our APIs have been running events like these for several years now.
@@MilanJovanovicTech Oh don't know. But there is always a chance that it might happen, but you are definitely right. If you are okay with having an external dependency then its all good. I do feel that people nowadays move away from the idea of not having external dependencies in your domain though just because it creates extra work.
@@donnyroufs551 mediatr is not really an external dependency, I mean sure it is, but it’s also super standard. A good solution for the purist approach like what you suggest (your not wrong btw) is to create an .Contracts project. And have all contracts shared here. The contracts project is the bridge between the layers
I'm new to DDD and currently half way through the O'Reilly book. In a recent chapter, the author warned against raising domain events in aggregates because a transaction may fail for some reason. At 4:10, you're raising a domain event in the aggregate before the unit of work persists the state of the aggregate, I believe. If subsequent operations were to fail for whatever reason, wouldn't any observers act on the event as if everything succeeded? Say, by sending out an invitation accepted email. Perhaps I'm misunderstanding what I read and/or how and where to raise domain events. Please advise.
It is said that Domain should not depend on any library or even should be framework neutral, but you are using the MediatR library in Domain. Can it be done without an external library and how? Thanks!
Hello. Can you please tell me how can I use clean architecture on Kotlin Android development? Or Can u point me to a playlist/channel that explains the same?
Hello, instead of using AgreegeareRoot, how can we use Markup interface so that we can deal with generic aggregate root as well when fetching all domain events and converting to outbox messages? Thanks!
@@MilanJovanovicTech Hi, I need your opinion on how to use this interface in change tracker to get domain events? I need generic aggregate root because my Id (PK) is not always either guid or integer.
I don't understand why should events be part of a list and not a queue? Isn't order of events important? EG: validating the card type, amount, then doing the actual payment, then trigger the next event... What if those are happening in "some" order?
@@MilanJovanovicTech But if I have a clean architecture using usecases. I have a usecase that needs 2 aggregates. However, the usecase should be within one transaction itself. Using eventual consistency we cannot do it right?
omg is it valid to put non standard MediatR in domain? no.... break of pattern domains have to be undestandable, with no 3rd party crap (especially if there is no source)
@@MilanJovanovicTechhow do u think, what will be more testable MediatR crap or auto generated pipes from design modeling tool? eventialy big project will use FSM and other concepts with no place for mediatr crap. and if pipes are generated than it is not duplication. It is even more desirable.
Get the source code for this video for FREE → the-dotnet-weekly.ck.page/domain-events
Want to master Clean Architecture? Go here: bit.ly/3PupkOJ
Want to unlock Modular Monoliths? Go here: bit.ly/3SXlzSt
I was waiting for this chapter, thank you very much Milan! This series is great!
There will be at least one more video showing how to persist domain events and publish them!
Awesome! The wait is over. wonderful series. Would love to see a separate video of the outbox pattern. Thanks.
Coming next week! Stay tuned 😁
One of the best practical explanations on how to implement domain-events that I have seen so far. Kudos to you.
That's a big compliment, thank you so much!
Hi Milan!
Thank you for the video! Can't wait when the next chapter about sending events is going to be published.
Hi Manya :) Most likely in 2 weeks, I already have a few videos prepared before that
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.
I wouldn't call what you did 'domain events' - but it's certainly the same idea
@@MilanJovanovicTech Isn't the point of domain and integration events to have them decoupled from the action that triggered them? Is there anything else I'm missing?
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
If that won't help, I'm working on a lengthy course. Hoping to have it released in July :)
And yet again a very informative video! Keep up the good work!
Thank you very much. Did you manage to apply one of the things I've shown on this chanmel?
@@MilanJovanovicTech Not yet in production software, but i'm trying to implement it in a personal project. This series really helps clarifying certain topics.
Pure magic; Thank you.
Just some clever coding, no magic here 😅
thank you very much Milan! This series is great!
You're most welcome!
amazing video, you are such a good instructor
Thanks a lot! :)
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.
Of course! Great spot :)
Good video! Thanks for sharing
Glad you liked it!
outbox pattern is the key to including domain events saved in a database with the transaction and introducing a background job to consume them
That's the next video: ua-cam.com/video/XALvnX7MPeo/v-deo.html
Sir your topic is very advanced
It is. Were you able to follow along?
Good video. Yes I think I will use it.
At least give it a try, you may find it useful :)
Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?
Yes
Great video, keep it up!
Thanks a lot Paul. Outbox pattern coming next week, to wrap this topic up 😁
@@MilanJovanovicTech Will you be using Hangfire for the background jobs? I am also interested in seeing how you implement UoW.
@@paulbarton2280 I usually use Quartz for that, since i can leverage the native HostedService in ASP.NET
UoW - Nothing special to be honest, just the DbContext. Maybe you had something more specific in mind? 🤔
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?
Yes, I had the same problem! This is why I resort to using a static factory pattern. Inside of that method you can call the ctor and raise the domain event. And you won't run into that issue
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.
Hi Pavel, I appreciate the comment!
- It's just a personal preference, I add the postfix to commands/queries/events by convention. I also use it because when I "Ctrl + T" in VS I can quickly navigate to the domain event and handler.
- That's a very interesting suggestion. I'm curious what is the benefit over validating the invariants inside of the command handler directly? We would still be inside of the main transaction, but the behavior would be explicit.
@@MilanJovanovicTech I think it depends on whether several commands can lead to the same event. Also, in Event Sourcing, events are the source of the state, but in our project, for example, we inverted the sequence: we call aggregate methods to change the state and events get published by aggregate itself.
Nice video Milan. Thanks! I working on a DDD with CQRS, event store, Onion Architecture and Azure service bus, project. i have a question based on your example.Wouldn't be better to have a folder in Application project named EventHandlers, and there to declare an event handler per entity, like InvitationEventHandler, and inside of this class we can handle all the events related to it. Or maybe other events related to other entities but which somehow can change the Invitation state or properties? Like this we can avoid having an event handler per event, we can end up in having a lot of events and of course a lot of event handlers. Or is this a best practice?
I lean towards grouping them closer together, easier to maintain.
Hello thx for amazing videos. I have question, should domain events be stored in agreggate in db, as a list what happened with aggregate like history? If yes how to deal with different structure of different events?
Store them as JSON... But you'll have to make each event backwards comaptible
Hi Milan i see you from Argentina, thanks you very much. How publish the domainEvent? its ok if i publish the domain event when the entity saved overriding the metod SaveChange of ef in this case or is better apply the outbox pattern?
I'm from Serbia 😁 Check out the Transactional Outbox pattern video, and also the recent domain events video
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.
Consider Clean Architecture - I would agree with you.
But it's important that we are *pragmatic* as engineers.
My thought:
- I don't think MediatR will introduce a breaking change (ever probably)
- Why would I switch implementation if this one gets the job done?
- Even switching would come down to using a different interface most likely
- As for rolling your implementation, I do think it's not too complicated to implement, but is it really worth the effort?
@@MilanJovanovicTech Well, i do understand your thoughts and i like to be pragmatic as well - so i would agree with you definitively for smaller projects. On the other hand: would it really be "measurable effort" of introducing own interfaces and some adapters right from the beginning? i never used MediatR on my own but wouldn't we talk about a few lines of code? And the increase in complexity (because of the indirection) would be minimal compared to the benefit of avoiding "broken window effect" right from the beginning.
i know this is rather philosophical discussion but it is good to have such discussions among software engineers ;-)
@@AboutCleanCode This problem is always there. It is important to be pragmatic and know where to draw the line. Architecture principles are there to guide us and prevent us from getting into a situation where it is difficult to maintain code or have agility in code. However, we should not be too dogmatic that we rather land in the same situation trying to implement it
@@MilanJovanovicTech I finally found the time to create a proof-of-concept of the ideas I have shared above: ua-cam.com/video/JGgeoB-tXJw/v-deo.html
That's why and many other don't like the Clean Architecture as a concept of separating the code. With more classic approach when using repositories + services/cqrs + controllers/endpoints you can get the job done without some really stupid restrictions. In the microservice world IMediatr is a wonderful thing which can hide inside other details for publishing events, like for example: publish an even using MediatR and after that put the event into Redis or some type of message queue.
Will I don't like the clean architecture I like the DDD. Each of them can live really well without each other
Are there tools for visualizing the resultant choreographed workflow? Flexibility is nice but it adds a ton of complexity when you need to know how its coupled to answer 'simple' business questions.
No there aren't any tools, at least to my knowledge. I agree that the flexibility is increased at the cost of complexity. But I find it well worth it in the long run.
Hey Milan, I really enjoy your content and have a few questions:
Would you recommend seperating domain objects and ef core entities fully? If not, why?
In the context of event sourcing and the likes, would you treat the relational query database like the email service and just notify it through domain events? Is that a stupid idea? I've played around with that idea a few times but found it pretty hard to implement in a smooth way.
Thanks!
- My Domain projects are my EF Entities, at the same time. I don't see much benefit in creating additional classes for EF Entities.
- Event sourcing can be quite difficult to manage on your own. But you could probably get by with raising Domain Events for every single change in the system. And then on the query side, processing those events and filling up your query model.
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.
Of course: ua-cam.com/video/XALvnX7MPeo/v-deo.html
Keep being awesome
You too, buddy!
What happens if I need to execute some business logic in the handler, for example to communicate the information that something has happened in my domain A and I need to do something in response in my domain B and a business error occurs? How can I roolback what has been done in domain A (let's say we're complement async) to keep data consistency?
What would cause the event handler to fail?
Don't stop!
Sure thing! 😁
Hey mate, How would you go about firing a domain event for entity deletion? Should I add a method to then entity such as "FlagForDeletion()" that raises an event that gets fired on save changes when the entity is removed from the repository?
Exactly like that, call a method that raises the event you need
Thanks
No problem
Hi, Milan thanks again for this rich content, I'm new to DDD and a bit confused my question is why we don't use events in c# with the pub/sub model for the implementation or it's not not a good approach, Thanks!?
Events are synchronous. Domaij eventa are asynchronous.
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
Even better I recorded a video discussing this earlier, and I'll release it in about 2 weeks :)
Hello Milan, I have customer in my domain. Can i create event as CustomerRegistrationComplated event or should be CustomerCreatedEvent which one correct ? also when user sign-in I publishing UserSignedIn event, is it domain event? Should we seprate that as busines events
I think CustomerRegistered or CustomerRegistrationComplated sounds much better than CustomerCreatedEvent.
What do you use the UserSignedInEvent for?
one question, what about if Emails service is another hosted application and has to send emails asynchronously would you prefer to raise a domain Event? or you will go for an integration event?
An integration event would probably be a good idea
Do domain events live in one instance only? How is it different from the "events" of distributed event-driven system?
They are not connected in any way. This is a _DomainEvent_ modeling something that occurred in your Domain.
Hi Milan,
if the business states "when an invite is accepted, send them an email". Now with the event we are leaking domain knowledge into the application layer as the application / infrastructure layer now decides what exactly we are doing with the event. We could send a sms instead an email and miss the business requirement.
What are your thoughts on this?
Actually, use cases of the business are defined and controlled by application (layer; where commands and command handlers are defined) so we’re all good here. So if the use case changes from sending an email to sending SMS, you would update the use case itself.
Rules regarding how gathering/invitations relation work from the business perspective hasn’t changed, so no need to touch the domain.
@Stjepan Karin Thank you the excellent response 😁
Great video. very helpful. I was waiting until de very end to check if you would talk about event concurrency when for example a consumer receives 2 events to an updated entity since it's dificult to garantee event processing order in a micro services enviorment. What are your thoughts about this? Maybe it's an idea for a future video :)
Of course I have a video 😁
Check this out:
ua-cam.com/video/mGeEtokcjVQ/v-deo.html
I also saw that video but the issue i was talking about was let's say entity A has an integer that has initial value 0 and receives an update to change it to 1 and at the same theres is another update that changes it to 2. Both update events are valid and are published sucessefully but depending on the order they arrive to the consumer there can be incosistent reactions. again this in a micro service enviorment
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.
I'll often do it to facilitate domain events. It's a tradeoff I'm comfortable making.
Got it, Thanks for replying
@@MilanJovanovicTech
Hey Milan, it's a great video! I just wanna ask a question, would not it be better to raise the domain event (for InvitationAcceptedDomainEvent) in the Accept method of the Invitation class? Because we need to call the Accept method to accept the invitation and then need to raise a domain event related to that. (in every place that needs this logic)
In our case, only the AggregateRoot can raise Domain Events. Invitation is an Entity, in the current design, so it can't raise Domain Events. If we changed our design so that Invitation is also an AggregateRoot, that would be perfectly fine.
@@MilanJovanovicTech Thanks.
@@MilanJovanovicTech Sorry to jump in..is there a reason why only AggregateRoot can raise Domain Events?
@@MartinoBordin Yes. You want you AggregateRoot to control your entire aggregate. So any modifications to the objects inside of the aggregate will flow through the AggregateRoot. Which is why it makes more sense to me to only allow the AggregateRoot to raise Domain Events.
Of course, if you feel this is too constraining - you can move the implementation to the Entity perhaps.
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
What are the chances of that happening, Donny?
Sometimes it's better to be pragmatic about it.
Worst case scenario, we implement our own IDomainEvent/IDomainEventHandler mechanism.
What should that be - a few hours of work when (if ever) needed?
I’m on the same boat as Milan. The MediatR handler infrastructure is great fit for a domain event handler, no need to make your own until proven necessary.
Our APIs have been running events like these for several years now.
@@MilanJovanovicTech Oh don't know. But there is always a chance that it might happen, but you are definitely right. If you are okay with having an external dependency then its all good. I do feel that people nowadays move away from the idea of not having external dependencies in your domain though just because it creates extra work.
@@donnyroufs551 mediatr is not really an external dependency, I mean sure it is, but it’s also super standard. A good solution for the purist approach like what you suggest (your not wrong btw) is to create an .Contracts project. And have all contracts shared here. The contracts project is the bridge between the layers
I'm new to DDD and currently half way through the O'Reilly book. In a recent chapter, the author warned against raising domain events in aggregates because a transaction may fail for some reason. At 4:10, you're raising a domain event in the aggregate before the unit of work persists the state of the aggregate, I believe. If subsequent operations were to fail for whatever reason, wouldn't any observers act on the event as if everything succeeded? Say, by sending out an invitation accepted email. Perhaps I'm misunderstanding what I read and/or how and where to raise domain events. Please advise.
Watch the next video on the Outbox pattern 😅
There's also a very recent video (from last week) about domain events, that's worth watching.
@@MilanJovanovicTech Thanks!
Hi Milan, Can you please share any real-time example where we can use this pattern?
What do you mean by real-time?
It is said that Domain should not depend on any library or even should be framework neutral, but you are using the MediatR library in Domain. Can it be done without an external library and how? Thanks!
Sure, implement publishing yourself 😅 I don't bother with that, this solution is perfectly acceptable for me
Hello. Can you please tell me how can I use clean architecture on Kotlin Android development? Or Can u point me to a playlist/channel that explains the same?
Hey Paul, I really can't advise you for Kotlin since I didn't work with that technology.
Can I have clean architecture without domain event and just using cqrs and repos
Yes
Quite an interesting solution structure!
Could you plz share the link on the GitHub repo of this project ?
I'm sure you'll find something here: github.com/m-jovanovic/
Hello, instead of using AgreegeareRoot, how can we use Markup interface so that we can deal with generic aggregate root as well when fetching all domain events and converting to outbox messages? Thanks!
Sure, why not. Although it won't add much value
@@MilanJovanovicTech Hi, I need your opinion on how to use this interface in change tracker to get domain events? I need generic aggregate root because my Id (PK) is not always either guid or integer.
Can you recommend some concise DDD books?
I honestly found videos/courses more useful for DDD. But take a look at Vaughn Vernon's "Implementing Domain-driven Design"
What would happen if SaveChanges failed, wouldn't the email still be sent?
Yup. Can't get around that.
please milan what is the meaning of boilerplate code ?
Code you have to write over and over, the plumbing to make your app work
why can't we use vanilla c# event instead of MediatR?
No dependency injection?
I don't understand why should events be part of a list and not a queue? Isn't order of events important?
EG: validating the card type, amount, then doing the actual payment, then trigger the next event... What if those are happening in "some" order?
One action can fire an event leading to the next action, so you can preserve order in that way.
this still does not talk about the transaction problem. If we need a transaction spanning multiple domain events how to do it?
There is no such thing, embrace eventual consistency
@@MilanJovanovicTech But if I have a clean architecture using usecases. I have a usecase that needs 2 aggregates. However, the usecase should be within one transaction itself. Using eventual consistency we cannot do it right?
@@singernooneheard6967 If you use a SQL transaction, you can maintain consistency across two aggregates for example. Be pragmatic.
thank you very much. you look like spider man
No one has ever told me that before, so thank you! 😁🕸️
omg is it valid to put non standard MediatR in domain? no.... break of pattern domains have to be undestandable, with no 3rd party crap (especially if there is no source)
Why wouldn't it be?
@@MilanJovanovicTechhow do u think, what will be more testable MediatR crap or auto generated pipes from design modeling tool? eventialy big project will use FSM and other concepts with no place for mediatr crap. and if pipes are generated than it is not duplication. It is even more desirable.
Sample doesn't show how to send a domain event, it is the most interesting question
Raising domain event: ua-cam.com/video/BimfDeDV4yU/v-deo.html
Publishing domain events is a separate video: ua-cam.com/video/XALvnX7MPeo/v-deo.html
I would like to know whether the girl who is an economist and works for Heineken is more of an economist or a brewer, then I consider.
I would like to know also