But is there a difference ? You can have a monolith and still develop in independent enough components. No need for a complex infrastructure if all you want is modularized code.
Two of my coworkers got into a really nasty fight about exactly this. We had a monolith codebase that was extremely modular, it was all one artifact with multiple entrypoints that might as well have been ships in the night except for a few common libraries to handle logging, tracing, metrics, and connection pooling to external services like mysql and rabbit. But we had one senior developer go on an entire crusade that our app wasn’t modular enough and what it boiled down to was in his mind is that if it wasn’t separate repos, separate artifacts, and a network boundary passing JSON or similar instead of serialized objects between them it wasn’t really modular.
I hate this kind of thought, if we go for his definition, literally every single application could be made '100% modular' by converting every single function into its own service, but instead of an ABI like stdcall you get an ABI that is json over the network.
At the end of the day modularity should _not_ be defined in terms of the interface between modules.
The main difference is the boundaries in a monolith are "soft" and can easily be worked around, changed, abused etc
With a service oriented architecture (micro or otherwise) the boundaries are enforced much more strictly by definition so can't be changed or worked around that easily
Has nobody used static analysis tools to enforce boundaries in CI? We could take the output of a module dependency tool and fail the build if it sees edges corresponding to independent modules importing each other.
