Finding your service boundaries - a practical guide - Adam Ralph

[@mg00]

Finally a decent video about this. Services are logical groupings of functionality in your business domain, and they have nothing to do with the physical deployment or structure (and computers don't care how the binaries are made or where they run). Developers thinking that microservices are about the physical boundaries is the biggest misunderstanding about microservices.

[@udirt]

loved it and had to laugh around 25:00... yes, true, yes, that.

[@allmhuran]

Hol'up. There's no meainingful difference between the option presented at ~13 minutes, and the option presented at ~16 minutes. The presenter just hand-waived over how the downstream services got all of that extra structured data "before" getting the order placed confirmation in the second case. In the first case this was apparently a problem, because if we want to add new functionality - like bitcoin payment - we have to extend the event structure, which creates coupling because downstream systems have to know how to consume that new structure. But in the second case... what? The downstream services magically have no difficulty with these new data structures because we created an id up front? Creating the order id up front or at the end makes absolutely no difference when it comes to solving the problem of how the rest of the order data was shared. And, uh oh, our decomposition is a little poor here. Changing a customer first name doesn't affect their status. Great. So there is no functional dependency from first name to status. Good so far. Therefore we put status in a different box. Oops. Changing a customer first name doesn't affect their last name. Great. So there is no functional dependency from first name to last name. Good so far. Therefore, using exactly the same logic, we put last name in a different box, right?

Each service is its technical authority meanig that the billing service not only owns the service backend code but it also owns a micro-front end used by the UI's shell. The service is independent all the way from the UI to the backend. When the user clicks bill this credit card or bill this bitcoin wallet, it is that micro-front end talking to the billing service letting it know that for order ID X this will be the billing information to use if the user ever completes the workflow (place the order). The speakers reiterates that from in minute 17:02 : he says -> "remember we've already told the billing service what the credit card details are.... DURING the workflow... now we can slim down the event to just an ID because those services are sitting there already with the data. You may want to check these other two videos: kzbin.info/www/bejne/aJq8lX6HjayMaKc and kzbin.info/www/bejne/eXS7aYalrZt1hLM

[@TheWarTurkey]

@ That's helpful, and I wish that Adam elaborated on that more in the talk. I'm watching this because I'm extremely new to event-driven systems, but I'm not new to generating an ID ahead of time and using that to pass to multiple systems. When he said "we've already told the billing service ..." I thought he meant that the sales service still collected all the information and passed it on to billing, just in a separate event or in the database, etc., which seems like it just moves the problem. I'm only at around the 18 minute mark so far, so hopefully I see more info as I watch more.