I have been working with event oriented architrctures for almost 10 years, and this is maybe the best explanation of the missconceptions og events i have ever seen. Great Video!
I love your videos! I watch them since about 2 years. Some videos i rewatch multiple times, and they get better and better each time i view them, because i digged deeper into that matter.
Thank you for all your videos. You are very good at explaining it. I have always been interested in patterns, but never really known when to use them. Currently, I'm working as the only developer building an E-commer/CRM/ERP for a company - a big task for one developer, I know. It started with the Mediator + CQRS patterns. Learned a lot while researching and experimenting in my own projects. Earlier I had been into the service pattern, but that alone has some limitations. It is a lot easier for everybody involved to reason about a project in terms of commands, queries and events.
ello.In carried transfer state,how would me managed changing of the state that is beeing transferred?I am thing that the event data is a serialisble dto that might change in time.How will we deal with.? And the second one , a log of events is feasable,in this case, Could help us?Thank you!
In my own app, in the Inventory context, I ended up creating a ProductQuantityUpdatedEvent containing the ProductId, QuantityAtHand, QuantityReserved, and QuantityAvailable. My thought was to avoid that the dependant domain is making unnecessary requests back for small amounts of data. And the receiver is probably interested in all those fields anyway. The ambition is to keep state transfer at a minimum. Sending just Ids for the most part.
Ya, the issue I've encountered with this is making sure you're only processing the newest message that you know about. Eg, if you have competing consumers, knowing when the event was published because you may be consuming an older message than one you already processed.
Hey Codeopinion, another masterpiece.. topics you cover are best in class... Just wanted to know how to make data consistency in event carried state transfer.. these are mainly master data... Like product, customer Waiting for a video on how sku will be generated in ui between services and data consistency in case of event carried state transfer....
What's the general strategy when you want to perform both business logic AND background tasks/side effects (such as sending emails, notifying websockets etc.) in response to the SAME event, within the same microservice? Would your handler have to perform business logic and also enqueue relevant background tasks, or is there a way to fan out the same event to different handlers within a microservice? Having to enqueue each background task manually seems like coupling, i.e. adding more side effects would mean you have to keep modifying your main business logic handler. Hope this makes sense...
Multiple consumers within the same service. For example, if you published a OrderPlacedEvent and you want to send an email and push info down to a client (websockets). I would have two consumers. One for the email and one for the websockets.
Here I am again, a year later, at a new firm and project. It still seems like Event Based Architectures are not used to its full potential, just sending messages between service. I see a value, when modelling and dealing with complexity, in expressing behavior in code as Events (and Commands), but many still feel comfortable seeing code as services with methods invoking methods in a chain of methods. This still the preferred pattern, and then they complain about complexity being to complicated to manage. I try to be empathetic towards them. I was in this stage as well before dicovering DDD and Event based architecture. I think that journey was what re-kindled my interest for software development - and not just programming. Too bad these skills are not looked for in our otherwise stressful environments.
Big organizations tend to prioritize people who get specific stuff "done" (finishes tasks) rather than those who come with new innovatibve solutions. It is a culture thing that affects all developers - most just get in line and do the minimal needed.
Thank you for this video. I am actually in the middle of my end of curriculum's project, and having issues to figure out how to deal with distributed transactions, most notably when it comes to rolling back in case of a potential error or something of this sort. I was wondering if using events only is enough, or do i need some sort of a workflow engine?
Check out the video I've done on Event Choreography and Orchestration as a way to avoid distributed transactions. ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-rO9BXsl4AMQ.html
Hi Derek! Imagine i push some changes / new functionality to a boundary, and that boundary now needs a local cache copy of data from another boundary. It will now receive data from that point on and forward, but what if it needs past data aswell? -- Does that indicate a bad design choice, or is there a common practice on how to seed the local cache?
Simply exposing that data somehow by a synchronous call is possible. But more so is why you need that data. It's not bad design that you need it, it depends why you need it. If you want to because it's common data (like a product name) that you want for display purposes, fine. But if it's data you need because it's apart of a command and business logic, that data might be in the wrong place.
Why someone would prefer event as notification over event carried state transfer. Is event carried state transfer not event notification + state. So, do you see any issues if events used for notification also carrying state information or is it more about intent of events.
I'd argue it comes often time down to boundaries. If you're passing a lot of state in messages and you're specifically using them for a local cache, then I'd be curious how your boundaries are defined. I'm not saying it's wrong because there are times where this can be useful pattern, but it probably should be a mix of both or more towards events as notifications. Also calling back to the producer to get more data isn't inherently bad if the action you're trying to perform isn't time sensitive.
Thanks for the great video. I belive in Azure they call Events with state - Messages. And Events for notifications - Events. Also they said that Message is something that must be processed by consumer. Which actually looks like a Command :) Can we say that Events with state are Messages? I know that both Event and Command are Messages. But I faced Azure confusing terminology. What do you think about it?
Hi Derek, Awesome video! For event carried state transfer, let's say a couple of services need to store some data about customers, but one of the services are down for some reason and missed customer related events for a while. What would be a good way to make sure it gets back in sync when it comes back up? (assuming event sourcing is not being used) Thanks for your content!
You want to have durable messages that don't necessarily have a time to live (or a long one that will work). Just because you can't consume a message because you're offline or there is an error processing it, you won't lose the message per say and will be able to re-consume it.
