[lolinder]

Yes. And the little-understood reason why microservices became the answer is that the tools for defining clear ownership boundaries in a single service were (and to an extent still are) lacking.

Defining a clear public contract in most existing programming languages that cannot be violated by a lazy programmer is tricky. Java's package-private should be the answer but is too blunt and ends up requiring a team to make things public so they can use them. C# has a bit more control that might make clear contracts possible (I haven't tried), but not everyone wants to use it because Microsoft. And most of the popular languages at the time of the rise of microservices had basically no mechanism for defining public versus private interfaces.

Microservices allow you to do that in any language— your HTTP API is your public interface. Anything inside of that is physically impossible to access without adding an explicit build-time dependency, which would be trivial to catch in code review.

Yes, code review could theoretically solve the same problems, but in practice no organization is that disciplined. You need tooling, and those tools didn't exist yet when microservices came to be. We're seeing them develop now (Rust's visibility modifiers are very powerful, and monorepo tools are starting to develop lints that can impose module boundaries on languages that lack them natively), and it's not a coincidence that around the same time we're seeing a lot of people moving back to monoliths.