That is more or less the approach that I would recommend to modern microservices, I would advise someone to read about domain-driven design and I would ask them to pay very careful attention to the notion of bounded contexts, the idea of a namespace for business level words. If you build your microservices partitioned at bounded context level, and you vehemently resist the idea of a remote procedure call—“under no circumstances are you giving me orders, you are maybe telling me about a state change that has happened to you, but don't you dare tell me what to do and when,” those two principles can guide a decent architecture. Have a message broker. Do “event storming” with non-technical users of the system to get a better model of the domain. Stuff like that.

And yet, I will contradict myself to say that actually, microservices have the potential to be that original vision of object-oriented programming from the 1960s. The fundamental idea is very cheap computational nodes that only interact by passing messages around, with the idea that a recursive design inspired by cells and biology, will be much more successful than traditional programming where you try to separate data structures from the procedures that operate on them. If your microservice has setters and getters, you're missing the point of this original vision of OOP. You could certainly build a system with 40,000 of these live, but probably you would not have 40,000 different chunks of source code behind them.