My understanding is that the point of microservices isn't to just move what would have been a relational join in SQL to an equivalent join in the service layer, which is what the author is implying. Instead, the order service should already have the subset of user data it needs to perform its function. If a user name changes, for example, that would trigger an event that gets consumed by a handler in the order domain. You embrace some denormalization and duplication of data in order for each service to have as much of what it needs to perform its function without a ton of other dependencies.
I'm not saying this is necessarily the way to go, I'm just saying that this is my reading of the microservices design pattern.
you're right, I'm in the middle of a big project where the lead engineer decided 'data duplication is forbidden'. The mess it created is terrible, both in complexity and in performance.
I can't imagine microservice architecture will ever work in a complex domain without every service having most of its dependent data in its own store.
What would help if people don't look at it as 'duplication' but rather 'caching'.
This is exactly correct and it took me a good while to understand this due to many people either not implementing this pattern or not knowing about it and then giving their 2 cents on microservices. Event sourcing and CQRS is the way to go.
Yeah, microservices and event sourcing go hand in hand.
Each microservice maintains its own database, with a model that is tailored to its own domain. This is called a projection, to illustrate that it is really the service's own view on the world, often with redundancy of data.
The service sources just the events it needs, and stores only the data it needs, to maintain this projection. It handles domain object lifecycle events in the way that makes sense for that particular service.
Without sounding condescending, but as a very late 'bloomer' - only working in development/software for 3 years and aiming towards an application architect role - I always thought this was the consensus.
It's similar to the "unit" in "unit testing": people will relate the most basic meaning to something they already understand, resulting in different, subtle distinctions.
In this case the breakdown actually seems the same to me as with the common unit testing misunderstanding - breaking down by syntactic form instead of conceptual form.
I'm not saying this is necessarily the way to go, I'm just saying that this is my reading of the microservices design pattern.