I feel like the solutions presented just make the problem more and more complex until reasoning about handling becomes intractable, but no real error handling improvement was actually made. I can't fathom what drives someone to think that if they struggle to solve a problem in a monolith, making it a distributed system would be easier For this particular shopping cart example, I feel like they need to normalize their tables better, and stop thinking that a row should map to an object. If you have products and listings (a product id + a price) as separate concepts then handling price changes is trivial: create a new listing and mark the old one as outdated. Then, you can check that prices are up to date when you read a shopping cart (which references listings instead of products) This looks a bit like event sourcing, but it just falls out from normalizing data and modelling the domain
A distributed system here is just a metaphor for separation of concern. Not separating concern in a monolith end up sooner or later as a ball of mud. In a big code base, your team will be split into areas. The devs focusing on the pricing management wont be handling the shopping cart. Decoupling is a best practice for that reason, and it's independent from distributed or not.
Well... I have so much to say )))... but I think there are two most important things worth to be mentioned. Understanding of read models as a cache - I believe is a brilliant guess. This is actually how I do it myself explaining read models to other peoples ). But important thing is that - unlike well-known caches in memcached that are outside of our application - read models are _in_ there. Understanding that fact makes some "problems", described in this talk, not a problems anymore. Stating that read models are owned by no one - also wrong. The coupling problem... Until you have to implement these handlers - it's not gone, nothing has changed. But! ) by removing orchestrating we just move from "mediator" pattern to "broker" pattern (that is well known choice for every architect), and I think it's not fair to select only pros of something-you-like, and only cons of something-you-don't-like ).
That last sentence is one of many things that are wrong with "society". We're in an industry of trade offs and every solution has to consider pros AND cons, not just only focusing on pros for things you like and cons for things you hate. If the pros outweigh the cons for the problem (not just all problems), that choice should be prioritized over everything else until a different problem challenges your current world view and you start the decision process all over again. Sure, you can make choices that prevent different types of problems from showing up, but this also means another set of problems show up and you'll either live with these existing problems or solve them.
Behavior should be what is important i software. Yet, a lot of developers are into data first. I feel it is hard to communicate with them. They always see the technical side before the behavior. Not that they ignore behavior, but going to the how-to is more important to them.
Well said. But for the program, I need to know the final state of the cart. User behavior is not important to me, only the current state is important to me.
When he said the engineer in the background started working I thought he was going to inspect how that banana case could contain bananas of all sizes and shapes. :)
Thanks Michal. GraphQL can be used to achieve a similar goal. Nginx as well can be used. However both of them are designed for different purposes, it's not easy to fit them into the mentioned scenarios.
Perhaps, we could still have the Cart and communicate via message, But the cart can only contain what it owns, the behavior of adding and item to the cart and changing the quantity can be owned by the cart, leaving the Cart with CartId, listOf(Item Ids), Quantity. Now for the writes the cart is self sufficient, for the reads the data can be fetched from relevant services using the respective Id.
(Thanks for the patience, there is no notification for comments on videos uploaded by others) It's doable. The downside is that quantity is needed by other services, sales to calculate the total price, and shipping to evaluate shipping options, making it so that the quantity stored in the Cart would need to be accessed outside of the cart itself, creating coupling.
@@mauroservienti But in the example, 3 services were coupled on quantity property, instead of just shopping cart owning the data it needs. Also: 1) How come Shipping service knows about quantity changes if you only publish thin events? 2) How come Marketing service knows about details of the cart, when sending that 7 days notification to a customer? 3) Why would Warehouse know about quantity of a cart in the first place, if it only checks if it's sufficient enough or not? 4) What about, lets say, notification email when order is completed, that basically should have all the data from services to create a body? 5) Absolutely terrible showcase of view model composition gateway, which works exactly the same as CQRS service would, gathering information from events and making 1 nice read model, but you add temporal coupling on top of that. Not even gonna mention some sorting/filtering, wonder how would u implement that (u would not). Looks like a LOT of artificial problems here, which CQRS + Saga would handle nice and easy.
Does this composition happens on Gateway level, or on Presentation layer? How can it be achieved if React is used on UI layer? (question relevant if composition is on UI level)
(Thanks for the patience, there is no notification for comments on videos uploaded by others) It depends on the scenario. The presented solution works at the gateway level (sort of reverse proxy type of approach). Conceptually the same logic can be implemented on the UI itself. I'm writing a blog post on a tangent topic, which will be published in a couple of weeks. A preview is here: github.com/mauroservienti/milestone.github.io/pull/231 Feel free to get in touch if you have any further questions, e.g. using the contact form on my blog: milestone.topics.it/about-me/
Here: github.com/ServiceComposer/ServiceComposer.AspNetCore/blob/master/src/ServiceComposer.AspNetCore/IHandleRequests.cs And demos for the talk are available here: github.com/mauroservienti/all-our-aggregates-are-wrong-demos/ For any code related concern, please do raise an issue on GitHub.
If this video had a million hits the whole industry would live in a much nicer reality.
Thanks ♥ !
This is gem of a session.
Thanks!
I feel like the solutions presented just make the problem more and more complex until reasoning about handling becomes intractable, but no real error handling improvement was actually made.
I can't fathom what drives someone to think that if they struggle to solve a problem in a monolith, making it a distributed system would be easier
For this particular shopping cart example, I feel like they need to normalize their tables better, and stop thinking that a row should map to an object.
If you have products and listings (a product id + a price) as separate concepts then handling price changes is trivial: create a new listing and mark the old one as outdated. Then, you can check that prices are up to date when you read a shopping cart (which references listings instead of products)
This looks a bit like event sourcing, but it just falls out from normalizing data and modelling the domain
A distributed system here is just a metaphor for separation of concern. Not separating concern in a monolith end up sooner or later as a ball of mud. In a big code base, your team will be split into areas. The devs focusing on the pricing management wont be handling the shopping cart. Decoupling is a best practice for that reason, and it's independent from distributed or not.
Well... I have so much to say )))... but I think there are two most important things worth to be mentioned.
Understanding of read models as a cache - I believe is a brilliant guess. This is actually how I do it myself explaining read models to other peoples ). But important thing is that - unlike well-known caches in memcached that are outside of our application - read models are _in_ there. Understanding that fact makes some "problems", described in this talk, not a problems anymore. Stating that read models are owned by no one - also wrong.
The coupling problem... Until you have to implement these handlers - it's not gone, nothing has changed. But! ) by removing orchestrating we just move from "mediator" pattern to "broker" pattern (that is well known choice for every architect), and I think it's not fair to select only pros of something-you-like, and only cons of something-you-don't-like ).
That last sentence is one of many things that are wrong with "society". We're in an industry of trade offs and every solution has to consider pros AND cons, not just only focusing on pros for things you like and cons for things you hate. If the pros outweigh the cons for the problem (not just all problems), that choice should be prioritized over everything else until a different problem challenges your current world view and you start the decision process all over again. Sure, you can make choices that prevent different types of problems from showing up, but this also means another set of problems show up and you'll either live with these existing problems or solve them.
Awesome! Great design thoughts.
"We are modeling behavior, not data" - So true!
Behavior should be what is important i software.
Yet, a lot of developers are into data first. I feel it is hard to communicate with them. They always see the technical side before the behavior. Not that they ignore behavior, but going to the how-to is more important to them.
Well said. But for the program, I need to know the final state of the cart. User behavior is not important to me, only the current state is important to me.
Very close to what I've heard from Jimmy Bogard's talk on NDC London few month before : "Compositional UIs - the Microservices Last Mile"
Great video, thank you for share us.
When he said the engineer in the background started working I thought he was going to inspect how that banana case could contain bananas of all sizes and shapes. :)
😆
Great spoon reference!
Great talk!
Great talk and great insights! What do you think about harnessing GraphQL to do the composition/decomposition job?
Thanks Michal. GraphQL can be used to achieve a similar goal. Nginx as well can be used. However both of them are designed for different purposes, it's not easy to fit them into the mentioned scenarios.
Excellent explanation. Totally agree that behaviour is more important than data and data is bi-product of behaviour.
Perhaps, we could still have the Cart and communicate via message, But the cart can only contain what it owns, the behavior of adding and item to the cart and changing the quantity can be owned by the cart, leaving the Cart with CartId, listOf(Item Ids), Quantity. Now for the writes the cart is self sufficient, for the reads the data can be fetched from relevant services using the respective Id.
(Thanks for the patience, there is no notification for comments on videos uploaded by others)
It's doable. The downside is that quantity is needed by other services, sales to calculate the total price, and shipping to evaluate shipping options, making it so that the quantity stored in the Cart would need to be accessed outside of the cart itself, creating coupling.
@@mauroservienti But in the example, 3 services were coupled on quantity property, instead of just shopping cart owning the data it needs.
Also:
1) How come Shipping service knows about quantity changes if you only publish thin events?
2) How come Marketing service knows about details of the cart, when sending that 7 days notification to a customer?
3) Why would Warehouse know about quantity of a cart in the first place, if it only checks if it's sufficient enough or not?
4) What about, lets say, notification email when order is completed, that basically should have all the data from services to create a body?
5) Absolutely terrible showcase of view model composition gateway, which works exactly the same as CQRS service would, gathering information from events and making 1 nice read model, but you add temporal coupling on top of that. Not even gonna mention some sorting/filtering, wonder how would u implement that (u would not).
Looks like a LOT of artificial problems here, which CQRS + Saga would handle nice and easy.
Does this composition happens on Gateway level, or on Presentation layer? How can it be achieved if React is used on UI layer? (question relevant if composition is on UI level)
(Thanks for the patience, there is no notification for comments on videos uploaded by others)
It depends on the scenario. The presented solution works at the gateway level (sort of reverse proxy type of approach). Conceptually the same logic can be implemented on the UI itself. I'm writing a blog post on a tangent topic, which will be published in a couple of weeks. A preview is here: github.com/mauroservienti/milestone.github.io/pull/231
Feel free to get in touch if you have any further questions, e.g. using the contact form on my blog: milestone.topics.it/about-me/
Does anyone know if all of Copenhagen’s lectures are in English?
So far yes, they've been all in English
Una chiarezza disarmante
Where is IHandleRequest coming from?
Here: github.com/ServiceComposer/ServiceComposer.AspNetCore/blob/master/src/ServiceComposer.AspNetCore/IHandleRequests.cs
And demos for the talk are available here: github.com/mauroservienti/all-our-aggregates-are-wrong-demos/
For any code related concern, please do raise an issue on GitHub.
Pleasant accent
Good talk
The shopping cart is a lie