with one click
nextjs-architecture
Structure Next.js projects with Feature-Sliced Design layers, domain-grouped slices, and strict import hierarchy. Use when organizing features into FSD layers, enforcing slice boundaries, or keeping page.tsx thin.
Menu
Structure Next.js projects with Feature-Sliced Design layers, domain-grouped slices, and strict import hierarchy. Use when organizing features into FSD layers, enforcing slice boundaries, or keeping page.tsx thin.
| name | nextjs-architecture |
| description | Structure Next.js projects with Feature-Sliced Design layers, domain-grouped slices, and strict import hierarchy. Use when organizing features into FSD layers, enforcing slice boundaries, or keeping page.tsx thin. |
| metadata | {"triggers":{"files":["src/features/**","src/entities/**","src/widgets/**"],"keywords":["FSD","Feature Sliced Design","slices","segments"]}} |
Warning: FSD introduces boilerplate. Use it only if project expected to grow significantly (e.g., 20+ features). For smaller projects, simple module-based structure preferred.
src/features/auth/login/ with ui/, model/, api/ segments.src/features/auth/login/index.ts.app/login/page.tsx (thin page).App (app/) -> Widgets -> Features -> Entities -> Shared
See implementation examples for thin page example.
app/ directory (App Router) only for Routing.page.tsx should only import Widgets/Features. No business logic (useEffect, fetch) directly in pages.src/components/LoginForm.tsx, src/hooks/useLogin.tssrc/features/auth/login/ containing both.App -> Widgets -> Features -> Entities -> Shared.Features or Pages. Move to Entities only when data/logic strictly reused across multiple differing features.shared/api, not entities.ui (Components), model (State/actions), api (Data fetching), lib (Helpers), config (Constants).components, hooks, services as segment names.For specific directory layout and layer definitions, see reference documentation.
Layer Imports: any layer import from layer ABOVE it? (App > Widgets > Features > Entities > Shared)
Page Logic: page.tsx thin, containing only Widgets/Features and zero useEffect/fetch?
RSC Boundaries: Server Components isolated from Client Components with proper 'use client' boundaries?
Public API: all access to slice performed via top-level index.ts (public API)?
Cross-Slice: slices within same layer (e.g., two features) import from each other directly? (Prohibited)
Server Actions: Place them in model/ folder of Feature (e.g., features/auth/model/actions.ts).
Data Access (DAL): Place logic in model/ folder of Entity (e.g., entities/user/model/dal.ts).
UI Components: Base UI (shadcn) belongs in shared/ui. Feature-specific UI belongs in features/*/ui.
page.tsx: Pages import Widgets/Features only; zero useEffect/fetch.features/auth/), not type (components/, hooks/).Standardize BRD and BRD-lite discovery for business goals, stakeholder impact, current-to-future state, and measurable value outcomes. Use when creating BRD, business case, project justification, ROI narrative, or AS-IS to TO-BE scope.
Standardize PRD discovery and drafting for product scope, user outcomes, requirement IDs, and acceptance criteria. Use when creating PRD, product requirements, feature specification, or acceptance criteria plan.
Standardize SRS and FRS specifications for technical behavior, interfaces, data contracts, quality constraints, and verification mapping. Use when writing SRS, functional specification, system behavior requirements, API/data contracts, or non-functional thresholds.
Clarify a rough product or engineering idea into a BRD-lite brief (Why) with measurable business value.
Turn an approved PRD or implementation goal into SRS/FRS technical requirements (How), architecture, contracts, and verification decisions.
Plan a feature from BRD-lite brief or clear intent into PRD (What), decisions, implementation plan, and task slices.