Domain-Driven Design in React

ReactMiddle~3 min read

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".

Short Answer

Interview ready

Premium

A concise answer to help you respond confidently on this topic during an interview.