In modern Angular development, particularly with NgRx SignalStore, the industry has shifted decisively toward a Feature-based structure over a type-based or strictly domain-layered one
. The goal is to keep code flat, isolated, and easy to locate
.
1. The Features Folder Structure (The 2026 Default)
The recommended approach is to organize your project by feature rather than by the type of file (e.g., putting all stores in one folder and all components in another)
.
What it looks like: Each feature folder (like /products or /cart) acts as a self-contained unit containing its own components, routes, and its specific SignalStore
.
Why it wins: It follows the locality of behavior principle, keeping business logic as close as possible to the route or UI that actually uses it
.
SignalStore Impact: Since SignalStore consolidates state, selectors (computed), and actions (methods) into a single file, it eliminates the need for complex, nested sub-folders for "actions" or "reducers"
.
2. Feature-Scoped vs. Domain-Scoped (Global)
While "Feature" and "Domain" are sometimes used interchangeably, the sources distinguish between them based on scope:
Feature-Scoped (Local): Most state should start here
. These stores are provided at the route level, meaning they are created when the user enters the feature and destroyed when they leave
. This improves startup performance and memory management
.
Domain-Scoped (Global/App-Wide): This is reserved for cross-cutting concerns that multiple features must share, such as auth, session, or user-preferences
. These are typically placed in a "core" or "global" directory and provided at the root level
.
3. Key Differences in the Modern Approach
Avoid "Type-Based" Nesting: Do not create folders named components/, services/, or stores/ inside every feature
. Keeping the structure flat makes it easier for team members to guess where code lives based on the filename alone
.
Standalone by Default: In modern Angular (v19+), NgModules are considered legacy
. Standalone components allow for a flatter dependency graph, further simplifying the folder structure because you no longer have to manage module wiring
.
Naming is Boring: Use clear suffixes like .store.ts, .component.ts, and .service.ts so the purpose of every file is immediate
.
Rule of Thumb: Default to a route-scoped feature store within a feature folder
. Only "promote" state to a global or domain-level folder if it is genuinely needed by more than one feature
.