Another amazing video, would also appreciate it if you would create a small end to end web api, ddd architecture project showcasing these concepts in an end to end project…
Great video! It would also be great if you could add scenarios where EDA is not suitable, i.e. it's simpler and cheaper to make those HTTP/gRPC calls instead
gRPC is synchronous and what I found through searching is its not suitable for loose coupling and also is synchronized while loose coupling is the motivation to use microservices. On the other hand, EDA is loose coupled and asynchronized.
Very informative video! Some follow-up questions- 1) I am having trouble understanding the difference between #2 and #4. Are they not both trying to orchestrate an internal process? 2) i have been trying to figure out how granular the events need to be. We have a Human Resources system, where they are trying to support Enterprise events that span use cases #1. 3 where the goal is to notify downstream systems of data change. We are evaluating the granularity of the events - e.g. it could be New Hire or Promotion or Separation, or one could go granular e.g. new hire future, new hire retro, new hire onboarding. When the consumers get the events, they have to make a call back to get the change. Do we in such a case define the granularity of the events based on the use cases and consumer needs? I have come across event storming but for use case #1, we don’t need to have events for things that are not relevant for the use case e.g. say item added to wish list. Sorry for the long question! I have been trying to understand this but haven’t been able to find any resources. Any pointers would be greatly appreciated.
1) #2 is talking about workflows and orchestrating that, yes. However #4 was talking about how those orchestrations can be temporally decoupled so you aren't bound by time. 2) I have a few videos that talk about Event-Carried State Transfer (ua-cam.com/video/qKD2YUTJAXM/v-deo.html and ua-cam.com/video/IzBEbfSg0uY/v-deo.html). Check those out and see if any of that helps. It really depends WHAT you're trying to do with events to determine what they should contain. If you have notification type events that are slim, often those are for workflow, and that's when you get into the callback situation. It's also important to know why other services need data.
Thanks for the video. The last part of it about temporal decoupling raised a question for me: What if we have a system where we have to fail after a while if one of the service is not responding. Since we are not waiting this service to do it's job, how we are going to know there is a failure? Setting a timeout for certain events to occur?
Yes, absolutely, that is one way. Check out this video, it will give you some ideas as you can use a time/expiry: ua-cam.com/video/PZm0RQGcs38/v-deo.html
Great video! But I was wondering if event-driven fits most of the cases in the late life-time of a project? I think there's a complication overhead with adding a broker and using event-choreography instead of having the whole work-flow in one place. From your experience you think it is worth it to start from the beginning with an event-driven architecture? or start with something simpler like service architecture and refactor later if things started getting complicated ?
This is a really good topic idea. EDA is great for established codebases. It allows you to build out more functionality that's decoupled from what you already have.
Do you have any views on syncing 'from' an external system? That is, pulling in a list of products on a regular, scheduled job? Btw great content from your channel!
Meaning another system is pulling data as a scheduled job? If so, nothing fancy other than if the amount of data it has to pull is very large. In that case it can be beneficial to have the initial request kick off it's own internal job or fan out the work into multiple smaller units. Giving the client back not the immediate response from the request, but an identifier or callback to provide it with the data once the request was processed.
For publishing, use an outbox or a fallback (ua-cam.com/video/tcePbob8rrY/v-deo.html). For consumers, well they just consume when the broker is available.
To send an email you should use a mail server and not a service from Amazon. This whole idea that the ownership of the entire IT infrastructure of the world needs to pass to 3-4 megamonopolistic companies is madness, no matter how many euphimisms we create to describe it. Other than that, thank you for the video.
Regarding temporal decoupling example, in NodeJs we can call warehouse and billing related methods asynchronously ( may catch them in their respective catch methods ). So, I believe that's correct and we may not need decoupling if we write code like that. Please comment. I do know you are explaining it from event driven architecture perspective but Node.Js is event driven, although we don't save those event like the kafka does. PS: I like the way you explain things by code and example.
They are two different things. Async programming models that are in-process are different than using durable queues to pass messages between processes, which is what I'm explaining in the video. I'm going to create another video to explain the differences.
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
Another amazing video, would also appreciate it if you would create a small end to end web api, ddd architecture project showcasing these concepts in an end to end project…
Great video! It would also be great if you could add scenarios where EDA is not suitable, i.e. it's simpler and cheaper to make those HTTP/gRPC calls instead
gRPC is synchronous and what I found through searching is its not suitable for loose coupling and also is synchronized while loose coupling is the motivation to use microservices. On the other hand, EDA is loose coupled and asynchronized.
Amazing! meaningful video. Thank you for sharing!
THIS IS LITERALLY THE BEST EDD Video I’ve seen ever
Well thanks!
Great video, great introduction to this vast topic
Very informative video! Some follow-up questions-
1) I am having trouble understanding the difference between #2 and #4. Are they not both trying to orchestrate an internal process?
2) i have been trying to figure out how granular the events need to be. We have a Human Resources system, where they are trying to support Enterprise events that span use cases #1. 3 where the goal is to notify downstream systems of data change.
We are evaluating the granularity of the events - e.g. it could be New Hire or Promotion or Separation, or one could go granular e.g. new hire future, new hire retro, new hire onboarding. When the consumers get the events, they have to make a call back to get the change. Do we in such a case define the granularity of the events based on the use cases and consumer needs? I have come across event storming but for use case #1, we don’t need to have events for things that are not relevant for the use case e.g. say item added to wish list.
Sorry for the long question! I have been trying to understand this but haven’t been able to find any resources. Any pointers would be greatly appreciated.
1) #2 is talking about workflows and orchestrating that, yes. However #4 was talking about how those orchestrations can be temporally decoupled so you aren't bound by time.
2) I have a few videos that talk about Event-Carried State Transfer (ua-cam.com/video/qKD2YUTJAXM/v-deo.html and ua-cam.com/video/IzBEbfSg0uY/v-deo.html). Check those out and see if any of that helps. It really depends WHAT you're trying to do with events to determine what they should contain. If you have notification type events that are slim, often those are for workflow, and that's when you get into the callback situation. It's also important to know why other services need data.
Thanks for the video. The last part of it about temporal decoupling raised a question for me:
What if we have a system where we have to fail after a while if one of the service is not responding. Since we are not waiting this service to do it's job, how we are going to know there is a failure? Setting a timeout for certain events to occur?
Yes, absolutely, that is one way. Check out this video, it will give you some ideas as you can use a time/expiry: ua-cam.com/video/PZm0RQGcs38/v-deo.html
@@CodeOpinion thank you for advice, i watched the video you suggested, it's really good.
You have my respect :D
Nice explanation. Do you have any book recommendation on EDA?
2 videos in a week… 🎉
Great video!
But I was wondering if event-driven fits most of the cases in the late life-time of a project?
I think there's a complication overhead with adding a broker and using event-choreography instead of having the whole work-flow in one place.
From your experience you think it is worth it to start from the beginning with an event-driven architecture?
or start with something simpler like service architecture and refactor later if things started getting complicated ?
This is a really good topic idea. EDA is great for established codebases. It allows you to build out more functionality that's decoupled from what you already have.
Which way do you want those events to flow typically?
When would you use queues over topics, seems like in my company we always have one queue per consumer and just publish messages there
In the warehouse example, we would have a queue - statemachine - warehouse -billing
Queues for Commands, Topics for Events
Do you have any views on syncing 'from' an external system? That is, pulling in a list of products on a regular, scheduled job? Btw great content from your channel!
Meaning another system is pulling data as a scheduled job? If so, nothing fancy other than if the amount of data it has to pull is very large. In that case it can be beneficial to have the initial request kick off it's own internal job or fan out the work into multiple smaller units. Giving the client back not the immediate response from the request, but an identifier or callback to provide it with the data once the request was processed.
What would happen if the Event Broker is unavailable?
For publishing, use an outbox or a fallback (ua-cam.com/video/tcePbob8rrY/v-deo.html). For consumers, well they just consume when the broker is available.
Thank you. Was quite helpful.
To send an email you should use a mail server and not a service from Amazon. This whole idea that the ownership of the entire IT infrastructure of the world needs to pass to 3-4 megamonopolistic companies is madness, no matter how many euphimisms we create to describe it. Other than that, thank you for the video.
Handling your own mail server, which I've done, is something I do not want to do or manage (at this at this point in time).
@@CodeOpinion True, I work in a corporate environment where these things just exist :)
Regarding temporal decoupling example, in NodeJs we can call warehouse and billing related methods asynchronously ( may catch them in their respective catch methods ). So, I believe that's correct and we may not need decoupling if we write code like that. Please comment.
I do know you are explaining it from event driven architecture perspective but Node.Js is event driven, although we don't save those event like the kafka does.
PS: I like the way you explain things by code and example.
They are two different things. Async programming models that are in-process are different than using durable queues to pass messages between processes, which is what I'm explaining in the video. I'm going to create another video to explain the differences.
I like to categorize events in 3 different "archetypes":
- Domain events
- RESTful events
- Signal events
Please elaborate
how is this video dated 11 MAy 2022 and today is May 8th???
Huh?