Microservices - which are related to what we're talking about - have so many benefits when done right. Teams can deploy independently and interactions between t

Microservices - which are related to what we're talking about - have so many benefits when done right. Teams can deploy independently and interactions between teams just become about API contracts or data relationships if we're talking aysnc systems / message passing. Sure, there is a whole lots of other complexity and issues (technical and organisational) that can arise here but, scale-aside, it is often about solving the problem of people working on a big system. A single monolith is hard to work on if your business requires continuous deployment type work flows for example. All that said, I'm a big fan of single applications where you don't need it. Eg single teams should often be striving to build single apps with well-defined boundaries and interfaces over putting these modules into their own services. You have to ask yourself why you're doing it. There are many reasons to do so but don't cargo cult and make your team's domain into twenty small services just for the sake of it. As with everything in software engineering, whether you should do something is answered by "it depends". What the OP is alluding too doesn't seem to reflect the nuanced reality out there or what many really think.