Project Structure in Angular

Enterprise Angular Directory Architecture Angular applications thrive on structure. Because Angular is a highly opinionated, full-featured framework, it enforces a standardized layout that scales predictably across large engineering teams. Modern Angular architecture has evolved to favor Standalone Components over legacy modules ( NgModule ). This architectural blueprint outlines an industry-standard, scalable project structure optimized for modern Angular applications utilizing standalone APIs, clean separation of concerns, and feature-driven modularity. The Workspace Blueprint When you initialize a new workspace using the Angular CLI ( ng new ), it generates a highly organized root configuration tree designed to manage compilation, linting, and environment variables. /my-angular-app ├── /src                         # Core application source code container │   ├── /app                     # Main application logic domain │   ├── /assets                  # Static physical assets (images, fonts, local JSON configurations) │   ├── favicon.ico              # Browser tab icon asset │   ├── index.html               # Single HTML container page served to the browser │   ├── main.ts                  # App bootstrap entry point file initializing standalone contexts │   └── styles.scss              # Global application-wide style declarations ├── angular.json                 # Core CLI workspace configuration (build, test, and asset paths) ├── package.json                 # Framework dependencies, third-party libraries, and execution scripts ├── tsconfig.json                # Main TypeScript compiler parameters └── tsconfig.app.json            # Strict TypeScript rules designated specifically for the application layer The App Domain Layout ( /src/app ) Inside the /src/app directory, code is organized by structural boundaries. This design pattern separates core singleton configurations, shared UI primitives, and domain-driven feature modules. /src/app ├── /core                        # Singleton infrastructure classes (Instantiated exactly once) │   ├── /guards                  # Route protection gates (auth.guard.ts, role.guard.ts) │   ├── /interceptors            # Network request filters (jwt.interceptor.ts, error.interceptor.ts) │   ├── /services                # Global core singleton data engines (auth.service.ts, theme.service.ts) │   └── core.config.ts           # Centralized core provider configuration array │ ├── /shared                      # Reusable visual primitives and stateless presentation utilities │   ├── /components              # Generic UI widgets used across many pages (button, modal, input) │   ├── /directives              # Custom attribute behavior markers (click-outside.directive.ts) │   ├── /pipes                   # Custom data transformers (safe-html.pipe.ts, time-ago.pipe.ts) │   └── /models                  # Global strict TypeScript data interfaces (user.model.ts, job.model.ts) │ ├── /features                    # Domain-driven feature sets (Modular, self-contained business units) │   ├── /auth                    # Authentication Domain │   │   ├── /pages               # Route-level components mapping to specific URLs │   │   │   ├── /login           # Login component grouping │   │   │   │   ├── login.component.ts   # Core layout code, reactive form logic, and state │   │   │   │   ├── login.component.html # Presentation markup template │   │   │   │   └── login.component.scss # Component-scoped private visual styles │   │   │   └── /register        # Registration view component │   │   └── auth.routes.ts       # Lazy-loaded child routing definitions for the auth domain │   │ │   ├── /jobs                    # Job Board Domain │   │   ├── /components          # UI elements private exclusively to the job feature (job-card) │   │   ├── /pages               # Layout pages (job-list, job-detail) │   │   ├── /services            # Context-specific data fetchers (job-data.service.ts) │   │   └── jobs.routes.ts       # Specialized job module routing parameters │   │ │   └── /mentorship              # Mentorship Module Domain │ ├── app.component.ts             # Root application structural layout housing the main <router-outlet> ├── app.config.ts                # Global application configuration file injecting core providers └── app.routes.ts                # Primary root navigation routing manifest mapping feature endpoints The Layered Component Anatomy Angular components are strictly structured into three matching files to segregate layout formatting, state logic, and visual presentation layer rules. The Logical Controller ( *.component.ts ): Written in TypeScript, this standalone file explicitly imports its dependencies directly inside its component decorator metadata block. It manages active states, inputs ( @Input ), outputs ( @Output ), and handles data-binding interactions using primitives like Signals . The Structural View ( *.component.html ): The HTML template layout utilizing Angular's native template block syntax ( @if , @for , @switch ) to map TypeScript data directly onto the rendered DOM tree. The Encapsulated Style ( *.component.scss ): Private, scoped style sheets. By default, styles specified here are compiled inside a shadow-like sandbox wrapper, preventing component layouts from unintentionally mutating global styles. Architectural Modularity Rules The Core Isolation Rule: The /core directory houses assets that are global in scope but contain zero direct presentation layout logic. They handle background infrastructure. This folder should never import assets from the /features or /shared directories to prevent cyclic dependency chains. The Shared Reusability Rule: Every component inside the /shared folder must be completely stateless and generic . A shared button component shouldn't know anything about an "authentication service"—it accepts configuration inputs, emits click event outputs, and allows external features to dictate its behavior. The Feature Encapsulation Pattern: The /features directory contains the core application business modules. Each feature folder (e.g., /auth ) operates like a miniature application—it bundles its own sub-components, internal page views, private database mapping services, and local lazy-loaded child routing configurations. This ensures that features can be refactored, moved, or deleted with zero cascading breakages elsewhere in the codebase.