Suggest an edit

Improve this article

Refine the answer for “Domain-Driven Design in React”. Your changes go to moderation before they’re published.

Approval required

Content

What you’re changing

Title (EN)

Short answer (EN)

Shown above the full answer for quick recall.

Answer (EN)

## What Domain-Driven Design (DDD) is

> **Domain-Driven Design** is an approach to software design,
> in which **the structure and logic of the application are built around the domain**,
> not around technologies, frameworks, or UI details.

---

### In simple words:

> "DDD is when the code reflects the **real business**, not the technical implementation."

---

## The core idea

DDD says:

> Split the system into **areas of domain meaning (domains)** -
> for example: users, orders, products, payments -
> and inside each area build code that reflects its business logic.

---

## An example in the context of React

Imagine an online store:

### Without DDD (by file type)

```javascript
components/
hooks/
pages/
utils/
```

> Everything is mixed together: UI, business logic, data.
> To understand how the cart works, you have to search for code across the whole project.

---

### With DDD (by domain)

```javascript
src/
  domains/
    user/
      model/
      api/
      ui/
    product/
      model/
      api/
      ui/
    cart/
      model/
      api/
      ui/
```

> Now everything related to the **cart**
> lives **inside one domain**.
> It is encapsulated and independent from the others.

---

## Key DDD principles that apply on the frontend

| Principle | Description | Example |
|---|---|---|
| **Bounded Context** | Each domain area (cart, user, product) is an isolated part of the system | `domains/cart` and `domains/user` do not know about each other directly |
| **Ubiquitous Language** | Use one shared language (domain terms) both in code and in business logic | Not `addItemToList`, but `addProductToCart` |
| **Encapsulation** | A domain hides its internal logic and exposes only a public API | `domains/cart/index.ts` exports `addToCart()` |
| **Separation of Concerns** | UI, state, and the business model are separated, but within the domain | `ui/`, `model/`, `api/` inside `cart` |
| **Composability** | Domains can be combined, but only through clear boundaries | `cart` can use `product` only through a shared contract |

---

## DDD and React

In React applications, DDD most often shows up through:

- **Feature-Sliced Design** - implementing `entities`, `features`, `pages` layers by domain;
- **Colocation** - keeping a domain's logic, UI, and models together;
- **Hooks and state models** (`useUserModel`, `useCartStore`);
- **Typed API models** (`domain/cart/model/types.ts`);
- **Public interfaces (index.ts)** - so each domain stays isolated.

---

## An example DDD + React structure

```javascript
src/
  shared/
    ui/
      Button.tsx
  domains/
    user/
      model/
        store.ts
        selectors.ts
        types.ts
      api/
        getUser.ts
      ui/
        UserAvatar.tsx
        UserProfile.tsx
      index.ts
    cart/
      model/
        store.ts
        selectors.ts
      api/
        addToCart.ts
        removeFromCart.ts
      ui/
        CartButton.tsx
        CartList.tsx
      index.ts
  app/
    providers/
    router/
    index.tsx
```

---

## How this combines with other principles

| Approach | What it gives | How it combines |
|---|---|---|
| **Atomic Design** | An organized UI | Can be used inside `shared/ui` |
| **Colocation** | Code next to where it is used | Each domain keeps its files locally |
| **Feature-Sliced Design** | Layers and dependency rules | DDD defines **what**, FSD defines **how** |
| **React Hooks** | Logic encapsulation | Each domain has its own hooks `useCart()`, `useUser()` |

---

## Advantages of DDD on the frontend

| Advantage | Description |
|---|---|
| A clear structure | Every piece of code belongs to a specific domain |
| Isolation | You can develop or refactor a single domain independently |
| A shared language with the business | Developers and managers use the same terms |
| Scalability | New domains can be added without chaos |
| Dependency control | Domains do not "know" each other's details |

---

## Summary

| What | Description |
|---|---|
| Idea | The architecture is built around **domains** (user, cart, product) |
| Core unit | A **domain** - a module that reflects business logic |
| Layers inside a domain | `model`, `api`, `ui`, `lib` |
| Principles | Bounded Context, Encapsulation, Ubiquitous Language |
| Goal | Matching the code structure to the business model, and easy scalability |

---

> **In React, DDD means your code reflects the real business, not just the UI.**
>
> Instead of "we have a Form component and a List component" ->
> you think "we have a User domain and a Cart domain".
</content>

Markdown · drag & drop images · ⌘B / ⌘I shortcuts704 words

For the reviewer

Note to the moderator (optional)

Visible only to the moderator. Helps review go faster.