Jan 12, 2026 • 6 min read
A practical architecture pattern for modules, services, and domain boundaries in production apps.
Key Takeaways
I split the API into domain modules first, then refine features inside each module. This keeps the codebase close to the business language and reduces cross-module coupling.
Each module owns its controllers, services, data access, and DTOs. The goal is to make features easy to find and test without digging through shared folders.
DTOs act as a firewall between internal models and public APIs. I define request/response DTOs at the module level and avoid leaking persistence shapes to the client.
When contracts change, the DTOs provide a clear diff and prevent accidental breakage across services.
Shared utilities live in a small core module: auth guards, interceptors, logging, and configuration. It stays intentionally thin so domain modules remain independent.
For data access, I keep repositories in the domain module so ownership stays clear. If a query is shared, it becomes a reusable service, not a shared database layer.