--- title: Day 4/30 — Modules Need Boundaries | daily.dev description: A short reminder that NestJS modules should encapsulate a meaningful business capability and expose only what other modules truly need. Exporting every... canonical: https://daily.dev/posts/day-4-30-modules-need-boundaries-xacstz9bx twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: Day 4/30 — Modules Need Boundaries | daily.dev og:description: A short reminder that NestJS modules should encapsulate a meaningful business capability and expose only what other modules truly need. Exporting every... og:url: https://daily.dev/posts/day-4-30-modules-need-boundaries-xacstz9bx og:image: https://api.daily.dev/og/posts/XAcstZ9bX.png og:image:alt: Day 4/30 — Modules Need Boundaries og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # Day 4/30 — Modules Need Boundaries **[Nestjs Developers](https://daily.dev/sources/nestjsdevs)** · [@ezilemdodana](https://daily.dev/ezilemdodana) · 1 min read · 28 upvotes · 13 comments ## Summary 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. ## Content 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: `OrdersModule` owns order creation, pricing and order state. Dangerous: `SharedModule` 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?  #NestJS #ModularArchitecture #TypeScript ## Community discussion Top comments from developers on daily.dev. **@lonewolf888** · 3 upvotes > 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... **@agustinbarrientos** · 1 upvotes > SharedModule owning the leftovers. Yep. **@andruhudz** · 1 upvotes > 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 **@akhlaqurrahmanomi** · 1 upvotes > Is it possible to make the modules almost decoupled? **@arlangalvez21** · 1 upvotes > 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. --- Tags: [#general-programming](https://daily.dev/tags/general-programming), [#typescript](https://daily.dev/tags/typescript), [#nestjs](https://daily.dev/tags/nestjs) [View this post on daily.dev](https://daily.dev/posts/day-4-30-modules-need-boundaries-xacstz9bx) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"DiscussionForumPosting","mainEntityOfPage":"https://daily.dev/posts/day-4-30-modules-need-boundaries-xacstz9bx","headline":"Day 4/30 — Modules Need Boundaries","text":"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.","url":"https://daily.dev/posts/day-4-30-modules-need-boundaries-xacstz9bx","datePublished":"2026-07-31T06:14:29.279Z","dateModified":"2026-07-31T18:17:36.855Z","author":{"@type":"Person","name":"Ezile Mdodana","url":"https://daily.dev/ezilemdodana","image":"https://media.daily.dev/image/upload/s--1OI8gwnO--/f_auto/v1771923757/avatars/avatar_7vB9SeLRKhOHGnzEpmFvQ?_a=BAMAMiiu0","description":"Software Project Lead sharing practical insights on NestJS, Angular, AWS and scalable systems.","interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"EndorseAction"},"userInteractionCount":8420}},"interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":28},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":13}],"comment":[{"@type":"Comment","text":"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.\nShared 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.\nIn 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.","datePublished":"2026-08-01T01:41:18.772Z","url":"https://daily.dev/posts/XAcstZ9bX#c-Zhi3F5bPM","author":{"@type":"Person","name":"Limited Lable","url":"https://daily.dev/lonewolf888","image":"https://media.daily.dev/image/upload/s--O0TOmw4y--/f_auto/v1715772965/public/noProfile"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":3}},{"@type":"Comment","text":"SharedModule owning the leftovers. Yep.","datePublished":"2026-07-31T16:59:06.320Z","url":"https://daily.dev/posts/XAcstZ9bX#c-ly2UChNy5","author":{"@type":"Person","name":"Agustin Barrientos","url":"https://daily.dev/agustinbarrientos","image":"https://media.daily.dev/image/upload/s--5ayxQnqn--/f_auto/v1788281802/avatars/avatar_wQYYVe5Tbj0NJ7C7qPoa8?_a=BAMAMicg0"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}},{"@type":"Comment","text":"Can anyone provide there good module structure ?\nI know there are a lot of examples in internet - but you can provide your structure why with pros and cons.\nThanks","datePublished":"2026-08-02T13:29:37.839Z","url":"https://daily.dev/posts/XAcstZ9bX#c-aSH8k6lOn","author":{"@type":"Person","name":"andru hudz","url":"https://daily.dev/andruhudz","image":"https://lh3.googleusercontent.com/a/ACg8ocL---snYLZfyby0hGSZRNE0HBZxFUaV8F3aRsSy8J8sc6V6Ew=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}},{"@type":"Comment","text":"Is it possible to make the modules almost decoupled?","datePublished":"2026-08-04T06:19:42.472Z","url":"https://daily.dev/posts/XAcstZ9bX#c-hIbZUX22f","author":{"@type":"Person","name":"Akhlaqur Rahman Omi","url":"https://daily.dev/akhlaqurrahmanomi","image":"https://lh3.googleusercontent.com/a/ACg8ocI1dnma6L1Di5ZW8C5WpjM5mpj16Hu409UEFxjQ6I3EyWSqcgYv=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}},{"@type":"Comment","text":"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.","datePublished":"2026-08-03T15:11:09.349Z","url":"https://daily.dev/posts/XAcstZ9bX#c-wooUUj3d4","author":{"@type":"Person","name":"Arlan Galvez","url":"https://daily.dev/arlangalvez21","image":"https://lh3.googleusercontent.com/a/ACg8ocJUS7uJkW5cquK3R9j4Blo6PpRTJpZSd-05hU6KLbMr6w=s96-c"},"interactionStatistic":{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":1}}],"isPartOf":{"@type":"WebPage","url":"https://daily.dev/squads/nestjsdevs","name":"Nestjs Developers"}} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Nestjs Developers","item":"https://daily.dev/squads/nestjsdevs"},{"@type":"ListItem","position":3,"name":"Day 4/30 — Modules Need Boundaries"}]} ```