Frontend Layered Architecture

Overview

Frontend directory structures should not collapse into “pages and everything else.” Type-revealing but role-ambiguous folders such as components, hooks, models, utils, and shared can absorb all code. This skill does not exist to force a large architecture. It exists to prevent business rules, API calls, URL state, and similar logic from unconsciously leaking into inappropriate folders during implementation.

Code should be separated into layers by role, dependency, external data boundary, and orchestration responsibility. Lower-level code must not be made aware of higher-level context.

This skill does not enforce a specific methodology such as Feature-Sliced Design or Vertical Slice Architecture. Type-based, feature-based, domain-driven, and other directory structures can all be valid. What matters is whether roles and dependency direction are clear within the structure the project has chosen, whether external data contracts are isolated, and whether code responsibilities and frontend-owned domain logic are managed effectively.

In an existing project, treat architecture as intentional only when it is documented, user-approved, or consistently recognizable through role, dependency, and Data boundaries. Otherwise, apply this skill's baseline to new and changed code instead of treating repeated placement as authority.

Common Foundation

If the project already uses layer terminology, prefer the project’s terms. Use the terms below only when there is no existing terminology, or when explaining structure. These abstract layer names are not default directory names; do not convert End-User, Domain, Shared, or Data into folders unless the user explicitly selected those names.