↓Skip to main content
  1. Posts/

Feature-based vs Domain-based folder structure in React

·3 mins

One of the most debated topics in frontend architecture is how to organize your folders. And if you’re building a mid-sized or large-scale React app, the structure you choose early on will either help you move fast or create pain that accumulates.

Two common strategies are:

  • Feature-based structure
  • Domain-based structure

Let’s break them down with real examples and explain when to use each.

Feature-based structure #

This approach groups files and components by functionality or features. Think of it as organizing your code by “what it does” (signup, dashboard, cart, etc).

When to use #

  • Projects with many isolated features.
  • Teams working in vertical slices.
  • You want to scale by shipping isolated features fast.

Folder layout #

Let’s say you’re building a banking app with login, dashboard, and transactions.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

src/
├── features/
│   ├── auth/
│   │   ├── components/
│   │   ├── hooks/
│   │   ├── services/
│   │   └── auth-screen.tsx
│   ├── dashboard/
│   │   ├── components/
│   │   ├── hooks/
│   │   └── dashboard-screen.tsx
│   └── transactions/
│       ├── components/
│       ├── hooks/
│       └── transaction-screen.tsx
├── shared/
│   ├── components/
│   ├── utils/
│   └── hooks/
└── app.tsx

In this structure:

  • Each feature owns its logic, UI, API calls.
  • You can easily move or delete a feature.
  • Shared code goes into shared/.

This structure works well for most teams and scales better than the classic flat folder mess.

Domain-based structure #

This structure is inspired by Domain-Driven Design (DDD) and groups files by business domains, not UI features.

You’ll see this more often in large enterprise systems, where different parts of the app reflect core business entities like User, Product, Order, etc.

When to use #

  • Complex business logic with domain boundaries.
  • Backend is structured by domain.
  • You want a clean separation between UI and business rules.

Folder layout #

Imagine you’re building an ecommerce dashboard. Your core domains are User, Product, and Order.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24

src/
├── domains/
│   ├── user/
│   │   ├── user-api.ts
│   │   ├── user-model.ts
│   │   └── user-service.ts
│   ├── product/
│   │   ├── product-api.ts
│   │   ├── product-model.ts
│   │   └── product-service.ts
│   └── order/
│       ├── order-api.ts
│       ├── order-model.ts
│       └── order-service.ts
├── ui/
│   ├── screens/
│   │   ├── product-list-screen.tsx
│   │   └── order-summary-screen.tsx
│   └── layout/
├── shared/
│   ├── utils/
│   ├── api/
│   └── types/
└── app.tsx

This structure:

  • Separates domain logic from presentation.
  • Makes it easier to test, scale, and reason about business rules.
  • Is powerful — but requires discipline.

So… which one should you use? #

Let’s be honest: most teams should stick with feature-based.

Why?

  • It’s simpler to understand.
  • It aligns better with how product teams work (build features).
  • It creates clear ownership and faster iteration.
  • It avoids premature abstraction.

Use domain-based only if:

  • Your app has real domain complexity.
  • You’re building internal tools for a larger system.
  • Your team understands and enforces boundaries.

Otherwise, don’t overengineer. A lot of teams say they’re doing “DDD”, but all they have is a domains/ folder collecting dust while everything happens in features/.

Final thoughts #

Don’t let architecture become religion.

Use feature-based to move fast with clarity.

Use domain-based when you’ve earned the complexity.

And don’t mix both unless your team knows exactly what they’re doing. Most don’t.

The best folder structure is the one your team can follow, scale, and maintain without a 30-minute onboarding call.