Refactoring occurs in similar ways: with strong interfaces between each of your microservices, you can change the implementation of your individual microservices (e.g., keep the payment processing microservice interface the same, but change the internals). Or you can also change which microservices get invoked (e.g., switch from v1 to v2 of a given microservice).
Yeah, but you do prevent refactorization across service boundaries. I feel as if you should really think twice before cementing your architecture like that.
Can you give me an example of why you can't refactor across service boundaries? In my mind, refactoring a service interface is the same as refactoring the interface (API) of an object. It's real work (tm) but definitely do-able.
I would imagine it's more a question of risk. If you're changing an interface inside your application boundaries, you can figure out pretty easily where the changed API is called and what you've got to do to fix it. If it's something on the edge of your microservice that is public, so who knows what unknown bits of code are open to breakage if you change your API, that's harder to track down and fix.
I don't know a ton about actually implementing this sort of thing, but from the outside looking in, this seems to be a common reason for API versioning.
