[ratww]

> With a monolith any random developer can go and flip some private method to public, import it way across the modules, and presto you are now building a ball of mud.

If "any developer" can do it, then the problem is not with monoliths, but rather with your pull request reviews process and lack of code ownership. This can even be helped by Github and other platforms with a CODEOWNERS file.

Microservices by themselves doesn't solve this problem. If anyone has commit access to all micro services, then they can make an even bigger mess, the same way.

[foobarian]

I haven't had experience with well isolated modules in a monolith so I'm likely not giving monolith enough credit here. It's possible a microservice organization may still have an advantage by having more of this isolation by default, instead of an uphill battle to get things set up properly.

[ratww]

If you are already doing code reviews, it is trivial to setup.

If you’re using microservices + monorepo, you need exactly the same thing, otherwise people will just commit in your service.

If you’re relying on multiple repositories, you can just split things within libraries and have the exact same effect. You can even have separate deployments with this arrangement.

Not to mention it is also an “uphill battle to get things set up properly” with microservices, so there’s really no advantage in using them for enforcing encapsulation.

But most important: a team unable to enforce encapsulation and code ownership is not ready for microservices at all.