Enjoyed this thanks! Really made me think about some decisions we made in a system I recently worked where we didn’t grasp what was possible with EDS and so fell back into REST ways of thinking.
Re 46:16 How does change data capture do anything for reliability? As described you just regenerated the command as a change event and the change event handler may fail exactly the same way as in the original command handler failed (to publish the event on the event bus). Why even bring up change data capture when you have a table with the data in question and you just need to know which commands failed to be published (column, or separate table including possible a dead letter box for "permanent" failures)?
Event driven applications is 18 years old. Event sourcing is even older and quite similar. Domain-Driven Design and particular bounded context is at least 15 years old and you figure out how to model this stuff (Event Storming is the current flashy name for the group activity). CQRS is 12 years old. There is nothing novel here other than the marketing of the 3 AWS services in this context. Just providing you with additional context. I enjoyed the presentation.
27:44 @serverlessjames it would be good to explain in the future how the order processing service got delivery address id to bake it in the event payload (is it a sync http get request from order processing service to delivery service, view model composition in the ui or something else).
7:50 This reversal is still bad in my perspective. You are creating a single point of failure unnecessarily. Using this specific example, there is no reason why Delivery Service and Pick-Up service shouldn't be just dependent on the Kitchen service.
Thanks for the feedback, I think this is actually just a problem with the diagram. Between each of the points of integration there would be some kind of event bus, so if the order service "failed" then all that would mean is that events aren't being published. This is good feedback though, Ill take it into future version of the talk. Thank you.
@@serverlessjames To be honest, I liked the talk overall, specially the concept that each service doesn't need or should be aware of everything that is happening. My criticism is mainly on the architecture with this example, which I feel doesn't take fully advantage of an event driven system and has a "bottleneck" by design. And that is even if you put the EventHub in the middle, it's still events that you go back and forth between the Order Processing Service and the others. Using this scenario in question, my point is that "Order Processing Service" should handle the order and trigger a "new order" event when a new order has been received and that's it. After that, Kitchen is most likely listening to that so it starts cooking. Kitchen can than issue an event "CookingStarted" or whever which includes the expected duration in case other services needs to prepare in advance (such as calling a courier) and another event at the end "CookingFinished". "Order Processing Service" could be listening to these just to update a customer view or whatever, but "Delivery Service" and "Pick-Up" services would have listened directly "new order" to know the the delivery type and than just wait for the "CookingFinished" event. This way, you have a natural flow of responsibility, where even if "Order Processing Service" dies in the middle of an order, the Kitchen doesn't care anymore is already cooking, and the delivery services don't care either as all they care is for the kitchen to finish cooking :) I have low experience as a programmer, however I'm a but addicted to minimizing hard dependencies and allow for flexibility in my solutions, by using architectures such as the Onion Architecture :)
Yeah I think you're absolutely right, and later in the talk I think I go through it in this same way. I'm going to refine the diagram for the next time I give a similar talk, so thankyou.
Such a professional, well presented talk! Fun, informative and the flow was perfect.
Enjoyed this thanks! Really made me think about some decisions we made in a system I recently worked where we didn’t grasp what was possible with EDS and so fell back into REST ways of thinking.
Re 46:16 How does change data capture do anything for reliability? As described you just regenerated the command as a change event and the change event handler may fail exactly the same way as in the original command handler failed (to publish the event on the event bus). Why even bring up change data capture when you have a table with the data in question and you just need to know which commands failed to be published (column, or separate table including possible a dead letter box for "permanent" failures)?
Great talk!
Thanks, James :)
Amazing session! I'm curious, Can someone share more light on the query part towards the 44:55 minute mark on the clip?
Thanks
Wow, this was incredibly thought-provoking and packed full of ideas, thankyou.
Event driven applications is 18 years old. Event sourcing is even older and quite similar. Domain-Driven Design and particular bounded context is at least 15 years old and you figure out how to model this stuff (Event Storming is the current flashy name for the group activity). CQRS is 12 years old. There is nothing novel here other than the marketing of the 3 AWS services in this context. Just providing you with additional context. I enjoyed the presentation.
The talk is still the best introduction I got to EDA. And the title is just that.
Thank you for a great talk!
Thanks for the great talk! Puts emphasis on what really drives the decisions when trying to build EDA
Great talk!
27:44 @serverlessjames it would be good to explain in the future how the order processing service got delivery address id to bake it in the event payload (is it a sync http get request from order processing service to delivery service, view model composition in the ui or something else).
Great feedback, thanks :)
So how would the OrderProcessingService get the DelvieryId?
Maybe capture the deliveryid in the session, so that OrderService knows the deliveryid?
Great talk, thanks!
Ok that quote at 51:15 is a bit much. It applies to a large number of software patterns most of which do that particulat thing better.
27:49 how would the event get deliveryAddressId ?
I assume it comes in the POST /order request. The user selected the address before placing an order
Does your events include the whole aggregate root and everything within?
If not, how do you handle out of order events?
roontime! 😆I love it!
👌
7:50 This reversal is still bad in my perspective. You are creating a single point of failure unnecessarily.
Using this specific example, there is no reason why Delivery Service and Pick-Up service shouldn't be just dependent on the Kitchen service.
Thanks for the feedback, I think this is actually just a problem with the diagram. Between each of the points of integration there would be some kind of event bus, so if the order service "failed" then all that would mean is that events aren't being published.
This is good feedback though, Ill take it into future version of the talk. Thank you.
@@serverlessjames To be honest, I liked the talk overall, specially the concept that each service doesn't need or should be aware of everything that is happening.
My criticism is mainly on the architecture with this example, which I feel doesn't take fully advantage of an event driven system and has a "bottleneck" by design.
And that is even if you put the EventHub in the middle, it's still events that you go back and forth between the Order Processing Service and the others.
Using this scenario in question, my point is that "Order Processing Service" should handle the order and trigger a "new order" event when a new order has been received and that's it.
After that, Kitchen is most likely listening to that so it starts cooking.
Kitchen can than issue an event "CookingStarted" or whever which includes the expected duration in case other services needs to prepare in advance (such as calling a courier) and another event at the end "CookingFinished". "Order Processing Service" could be listening to these just to update a customer view or whatever, but "Delivery Service" and "Pick-Up" services would have listened directly "new order" to know the the delivery type and than just wait for the "CookingFinished" event.
This way, you have a natural flow of responsibility, where even if "Order Processing Service" dies in the middle of an order, the Kitchen doesn't care anymore is already cooking, and the delivery services don't care either as all they care is for the kitchen to finish cooking :)
I have low experience as a programmer, however I'm a but addicted to minimizing hard dependencies and allow for flexibility in my solutions, by using architectures such as the Onion Architecture :)
Yeah I think you're absolutely right, and later in the talk I think I go through it in this same way. I'm going to refine the diagram for the next time I give a similar talk, so thankyou.
While you are at it :) there's a typo in 10:20, should be "its" instead of "it's".
Deadlocks? Cycles?
Brilliant talk, thank you!