Feature Modules in Angular
Learn Angular Feature Modules with architecture, organization, lazy loading, routing, shared modules, core modules, standalone migration, enterprise best practices, and interview questions.
Note: Since Angular 17+, Standalone Components are the recommended approach for new applications. However, Feature Modules (NgModules) remain important because:
- Many enterprise applications still use them.
- Existing projects continue to rely on them.
- Interviews frequently include Feature Module questions.
- Teams often migrate gradually from Feature Modules to Standalone Components.
Feature Modules organize an Angular application into business-focused units.
Instead of placing everything inside one large application module, Feature Modules divide the application into logical areas such as:
- Authentication
- Customers
- Orders
- Payments
- Reports
- Administration
This organization improves scalability, maintainability, and team collaboration.
Table of Contents
- What are Feature Modules?
- Why Use Feature Modules?
- Feature Module Architecture
- Types of Angular Modules
- Creating Feature Modules
- Routing with Feature Modules
- Lazy Loaded Feature Modules
- Shared Module vs Core Module
- Standalone Components vs Feature Modules
- Enterprise Banking Example
- Best Practices
- Common Mistakes
- Top 10 Interview Questions
- Interview Cheat Sheet
- Summary
What are Feature Modules?
A Feature Module groups related functionality into a single unit.
A Feature Module usually contains:
- Components
- Services
- Models
- Routing
- Pipes
- Directives
- Guards
- Tests
Each feature owns its own business functionality.
Why Use Feature Modules?
Benefits include:
- Better code organization
- Improved maintainability
- Easier team collaboration
- Modular architecture
- Supports lazy loading
- Smaller initial bundle size
- Easier testing
- Better scalability
Feature Module Architecture
flowchart TD
Application
Application --> AuthenticationModule
Application --> CustomerModule
Application --> PaymentModule
Application --> LoanModule
Application --> ReportModule
AuthenticationModule --> Components
CustomerModule --> Components
PaymentModule --> Components
LoanModule --> Components
ReportModule --> Components
Angular Module Types
| Module | Purpose |
|---|---|
| AppModule | Root application module |
| Feature Module | Business functionality |
| Shared Module | Reusable UI components |
| Core Module | Singleton services |
| Routing Module | Route configuration |
Typical Project Structure
src/
└── app/
├── core/
├── shared/
├── authentication/
├── customers/
├── accounts/
├── payments/
├── loans/
├── reports/
└── app.module.ts
Creating a Feature Module
@NgModule({
declarations: [
CustomerListComponent,
CustomerDetailComponent
],
imports: [
CommonModule,
CustomerRoutingModule
]
})
export class CustomerModule {}
The module contains everything related to customer management.
Feature Module Responsibilities
A Feature Module should contain:
- Feature components
- Feature services
- Feature routes
- Feature models
- Feature guards
- Feature pipes
Avoid placing unrelated functionality inside the same module.
Feature Module Flow
flowchart LR
FeatureModule
FeatureModule --> Components
FeatureModule --> Services
FeatureModule --> Routes
FeatureModule --> Models
FeatureModule --> Guards
Routing with Feature Modules
Example
const routes: Routes = [
{
path: '',
component: CustomerListComponent
},
{
path: ':id',
component: CustomerDetailComponent
}
];
Each feature maintains its own routing configuration.
Lazy Loading Feature Modules
Lazy loading loads a module only when it is needed.
Example
{
path: 'customers',
loadChildren: () =>
import(
'./customers/customer.module'
)
.then(
m => m.CustomerModule
)
}
Benefits
- Faster application startup
- Smaller initial download
- Better performance
Lazy Loading Architecture
flowchart LR
Browser
Browser --> AppModule
AppModule --> Dashboard
Dashboard --> CustomerModule
Dashboard --> PaymentModule
Dashboard --> LoanModule
Only the requested module is downloaded.
Shared Module
The Shared Module contains reusable UI building blocks.
Examples
- Buttons
- Cards
- Tables
- Pipes
- Directives
- Reusable Components
Example
@NgModule({
exports: [
TableComponent,
CardComponent,
CurrencyPipe
]
})
export class SharedModule {}
Shared Modules should avoid providing singleton services.
Core Module
Core Module contains application-wide services.
Examples
- Authentication
- Logging
- Configuration
- Error Handling
- HTTP Interceptors
Example
@NgModule({
providers: [
AuthService,
LoggerService
]
})
export class CoreModule {}
Core services are intended to have a single application-wide instance.
Core vs Shared vs Feature
| Module | Purpose |
|---|---|
| Core | Singleton services |
| Shared | Reusable UI |
| Feature | Business functionality |
Feature Module Communication
flowchart LR
CustomerModule
CustomerModule --> SharedModule
CustomerModule --> CoreModule
PaymentModule --> SharedModule
PaymentModule --> CoreModule
Feature modules should communicate through shared services, routing, or well-defined APIs rather than tightly coupling directly to each other.
Standalone Components vs Feature Modules
Modern Angular favors Standalone Components.
Example
bootstrapApplication(
AppComponent,
{
providers:[
provideRouter(routes)
]
});
Comparison
| Feature Modules | Standalone Components |
|---|---|
| NgModule Required | No NgModule |
| More Boilerplate | Less Boilerplate |
| Mature Enterprise Support | Modern Angular |
| Common in Legacy Apps | Recommended for New Apps |
Many organizations use a hybrid approach during migration.
Enterprise Banking Example
Application
Banking App
├── Authentication
├── Customers
├── Accounts
├── Payments
├── Loans
├── Investments
├── Reports
└── Administration
Each business area is implemented as an independent feature.
Enterprise Architecture
flowchart TD
BankingApplication
BankingApplication --> AuthenticationModule
BankingApplication --> CustomerModule
BankingApplication --> AccountModule
BankingApplication --> PaymentModule
BankingApplication --> LoanModule
BankingApplication --> InvestmentModule
AuthenticationModule --> Backend
CustomerModule --> Backend
AccountModule --> Backend
PaymentModule --> Backend
LoanModule --> Backend
InvestmentModule --> Backend
Migration to Standalone Components
Many enterprise applications migrate incrementally.
Migration strategy
- Convert new components to standalone.
- Keep existing Feature Modules working.
- Replace module-based lazy loading with standalone lazy loading.
- Remove unused NgModules gradually.
This reduces migration risk while modernizing the application.
Performance Best Practices
| Practice | Benefit |
|---|---|
| Lazy Load Features | Faster startup |
| Keep Modules Small | Better maintainability |
| Group by Business Domain | Clear ownership |
| Use Shared Module for UI | Reusability |
| Keep Singleton Services in Core | Avoid duplicates |
| Avoid Circular Dependencies | Better architecture |
| Prefer Standalone for New Code | Modern Angular |
| Optimize Bundle Size | Faster loading |
Common Mistakes
Creating Huge Feature Modules
Large modules become difficult to maintain.
Split large domains into smaller business features when necessary.
Putting Singleton Services in Shared Modules
Singleton services belong in the Core Module or application-level providers.
Circular Module Dependencies
Avoid:
CustomerModule
↓
PaymentModule
↓
CustomerModule
This creates maintenance and dependency problems.
Everything in AppModule
Do not place all components and services inside one root module.
Ignoring Lazy Loading
Large features should be lazy loaded whenever possible.
Feature Module Best Practices
| Practice | Recommendation |
|---|---|
| Organize by Business Feature | Yes |
| Lazy Load Large Features | Yes |
| Small Focused Modules | Yes |
| Shared UI in Shared Module | Yes |
| Singleton Services in Core | Yes |
| Avoid Circular Dependencies | Yes |
| Prefer Standalone for New Apps | Yes |
| Incremental Migration | Yes |
Feature Modules vs Standalone Components
| Feature | Feature Modules | Standalone Components |
|---|---|---|
| NgModule Required | ✅ | ❌ |
| Recommended for Legacy Apps | ✅ | ✅ |
| Recommended for New Apps | Limited | ✅ |
| Lazy Loading | ✅ | ✅ |
| Boilerplate | Higher | Lower |
| Tree Shaking | Good | Better |
| Migration Friendly | Existing Apps | Modern Angular |
Advantages
| Benefit | Description |
|---|---|
| Better Organization | Business-based structure |
| Modular Development | Independent features |
| Easier Maintenance | Smaller codebase sections |
| Lazy Loading | Better performance |
| Team Collaboration | Clear ownership |
| Enterprise Ready | Proven architecture |
Top 10 Feature Module Interview Questions
1. What is a Feature Module?
Answer
A Feature Module is an Angular NgModule that groups related business functionality such as components, services, routing, and models into a single logical unit.
2. Why use Feature Modules?
Answer
Feature Modules improve organization, maintainability, scalability, team collaboration, and support lazy loading.
3. What should a Feature Module contain?
Answer
A Feature Module typically contains:
- Components
- Services
- Routing
- Models
- Guards
- Pipes
- Directives
- Tests
4. What is lazy loading?
Answer
Lazy loading loads a feature only when users navigate to it, reducing the initial bundle size and improving startup performance.
5. What is the difference between Core Module and Shared Module?
Answer
The Core Module contains singleton services used across the application, while the Shared Module contains reusable UI components, directives, and pipes.
6. Can Feature Modules communicate directly?
Answer
They should communicate through shared services, routing, or well-defined APIs instead of tightly depending on one another.
7. Are Feature Modules still relevant?
Answer
Yes. Although Standalone Components are recommended for new Angular applications, Feature Modules remain common in enterprise applications and interview discussions.
8. Why avoid circular dependencies?
Answer
Circular dependencies increase complexity, make maintenance harder, and can lead to build or runtime issues.
9. Should new Angular projects use Feature Modules?
Answer
New Angular projects typically favor Standalone Components. However, Feature Modules may still be appropriate for existing applications or gradual migrations.
10. What are Feature Module best practices?
Answer
- Organize by business domain
- Keep modules focused
- Lazy load large features
- Use Shared Module for reusable UI
- Keep singleton services in Core
- Avoid circular dependencies
- Adopt Standalone Components for new development
Interview Cheat Sheet
| Topic | Recommendation |
|---|---|
| Business Organization | Feature Modules |
| Reusable UI | Shared Module |
| Singleton Services | Core Module |
| Navigation | Feature Routing |
| Performance | Lazy Loading |
| Modern Angular | Standalone Components |
| Migration Strategy | Incremental |
| Team Collaboration | Business Ownership |
| Scalability | Modular Design |
| Enterprise Projects | Hybrid Architecture |
Summary
Feature Modules have been a foundational architectural pattern in Angular for organizing applications into business-focused units. While modern Angular recommends Standalone Components for new development, Feature Modules remain essential for maintaining and evolving existing enterprise applications. Understanding how Feature Modules, Shared Modules, Core Modules, and lazy loading work together is valuable for designing scalable Angular applications and succeeding in Angular interviews.
Key Takeaways
- ✅ Feature Modules organize applications by business capability.
- ✅ They improve scalability, maintainability, and collaboration.
- ✅ Large features should be lazy loaded.
- ✅ Shared Modules contain reusable UI components.
- ✅ Core Modules contain singleton services.
- ✅ Avoid circular dependencies between modules.
- ✅ Standalone Components are the recommended approach for new Angular applications.
- ✅ Many enterprise projects use a hybrid architecture during migration.
- ✅ Feature Modules remain a common Angular interview topic.
- ✅ Understanding both NgModule-based and standalone architectures is important for senior Angular developers.
Next Article
➡️ 121-Standalone-Components-Architecture-QA.md