Requiring numerous large interfaces is a True Truth about your code. You didn't make anything go away by just giving up. You just forstalled any other future op

Requiring numerous large interfaces is a True Truth about your code. You didn't make anything go away by just giving up. You just forstalled any other future options. The complexity was there regardless. I suspect it is likely you did not do the interface minimization, which I didn't have time to go into. You should not hand "a file system" to your code when it does not need it; if all it needs is to "read a file by file name" then the interface it receives should have only that. If you have the occasional module that takes 25-50 inputs, I just pay the price for that particular module. If every module in your system is taking dozens upon dozens of inputs, you aren't building a "modular monolith", you're just building a monolith with extra random cuts in it, which is the worst of both worlds. You can take an architecture diagram and drop an arbitrarily complicated line across any bit of it. The resulting code will also be arbitrarily complicated, but you can do it. (See also what microservice architectures tend to become anyhow.) But if you keep dropping lines across your architecture and they're all really, really complicated, the problem is your procedure for drawing those lines, not the utility of a separated architecture. This is one of the reasons I'm not a big fan of rigidly following "clean" or "hexagonal" or any other particular architecture, because even as they have good ideas, rigidly following them inevitably involves drawing overcomplicated lines across the architecture. They're useful ways to get started but true design taste requires an inexpressible understanding of where to cut things that none of them can hand to you as a rigid recipe.