A NestJS module is not just a folder with a decorator.
It should own a meaningful business capability and expose only what other modules genuinely need.
Good: <code>OrdersModule</code> owns order creation, pricing and order state.
Dangerous: <code>SharedModule</code> owns everything nobody knew where to put.
Exporting every provider creates hidden coupling. Eventually, every module can reach into every other module.
Keep internals private. Export deliberate capabilities.
What is the first sign that a module has become too large?
<img src="https://media.daily.dev/image/upload/s--BYTGh39S--/f_auto/v1785478458/ugc/content_613c6da9-5cbe-4bbb-b5ab-49863f275175?_a=BAMAMicg0" alt="nest04.png">
#NestJS #ModularArchitecture #TypeScript

Welcome to the NestJS Developers Hub, a collaborative community for developers passionate about NestJS! Whether you're a seasoned expert or just getting started, this group is dedicated to sharing knowledge, solving problems, and advancing our skills

Nestjs Developers

A short reminder that NestJS modules should encapsulate a meaningful business capability and expose only what other modules truly need. Exporting every provider leads to hidden coupling, where any module can reach into any other. The advice: keep internals private and export deliberate capabilities. A SharedModule that holds everything nobody knew where to put is flagged as a common anti-pattern.

Day 4/30 — Modules Need Boundaries

Yes, I recently worked on restructuring a Node.js + TypeScript project using a modular architecture. Since the application is ERP-based and organized into domain-specific modules (similar to a microservices mindset), we designed each module to own its complete business capability, including its services, controllers, and related logic.
Shared code is kept to a minimum and limited to common utilities, helpers, and cross-cutting concerns. This approach reduces tight coupling, makes the codebase easier to maintain, and allows each module to evolve independently.
In my experience, the first sign that a module has become too large is when it starts handling multiple business responsibilities or when other modules depend on its internal implementation instead of its exposed capabilities.

SharedModule owning the leftovers. Yep.

Can anyone provide there good module structure ?
I know there are a lot of examples in internet - but you can provide your structure why with pros and cons.
Thanks

Is it possible to make the modules almost decoupled?

The module has become too large if you need to import it into other places to perform a simple action that is unrelated to the goal or specifics of the required module. If the scope of what needs to be done is getting too large, it’s time to refactor. Adopt the mindset that each module should provide domain-specific actions.