Modular monolith: the overlooked middle ground?

i've been advocating for a modular monolith approach lately, especially after seeing several teams at work struggle with premature microservices. they end up with a distributed monolith that's harder to manage than the original monolith. the idea is to keep everything in one codebase and deployment unit but enforce strict module boundaries, using internal APIs or clear package structures. this gives you microservice-like separation of concerns without the operational overhead. what's challenging is enforcing those module boundaries effectively, especially regarding database access. should each module have its own schema/tables and communicate via events, even within the monolith? or is a shared database with strict access patterns for each module sufficient? i'm looking for practical advice on implementing and maintaining module separation in this model.