There are two aspects here I think. Modularity in terms of code, and modularity in terms of deployment lifecycle. As you say most dependency problems can be h

There are two aspects here I think. Modularity in terms of code, and modularity in terms of deployment lifecycle. As you say most dependency problems can be handled at the level of the code, depending on how you structure the builds etc. ( personally I think automatically pulling in dependencies is a mistake - it should be slightly painful to add a new dependency ). For me, the reason for microservice like deployment is having a separately lifecycle - being able to start,stop, update separately from other services. Another aspect which I don't think is talked about enough, is that every deployment has a copy of the code ( in whatever executable form ) - this means I can deploy version 1 of code A in service X and version 2 in service Y at the same time if I need to - ie I can incrementally update the system. So one way to think about what should be deployed together ( or not ) is thinking not about the code per se - but also the natural deployment cycle.