Domain-Driven Design and Its Relationship with Redux

Redux creator Dan Abramov admits he does not know Domain‑Driven Design (DDD), yet the two share many architectural principles. This article introduces DDD, its strategic and tactical layers, and maps those ideas to Redux.

Domain‑Driven Design Overview

DDD is a software modeling technique for building robust micro‑service architectures and integrating existing solutions. It was introduced by Eric Evans in 2003 and has since expanded with many books and examples. DDD is divided into strategic and tactical sub‑domains.

Strategic DDD defines a ubiquitous language and bounded contexts, creating a common vocabulary shared by developers and business stakeholders across documentation, stories, and code. It focuses on system implementation, aiming for scalability across many micro‑services using abstractions such as queries, commands, domain events, and aggregates.

Tactical DDD includes concrete concepts:

Query : a read‑only request that returns information without side effects (e.g., list available posts).

Command : a request to change state; it may succeed or fail (e.g., add a new post).

Domain Event : a fact that has already occurred; it cannot fail or be cancelled, and any component can listen to it to update its own state.

Aggregate : a cluster of related domain objects (typically one entity and several value objects) that communicate via queries, commands, and events.

Mapping DDD to Redux

Although Redux does not use the same terminology, its concepts align closely with DDD:

Queries correspond to selectors that read state.

Commands correspond to actions dispatched to the store; Redux does not return results, following a pure CQS model.

Events are also actions, but once an action is reduced it becomes a fact—an immutable occurrence.

Aggregates map to reducers that compute all state changes.

Event Sourcing and CQRS in Redux

DDD promotes event sourcing to increase write throughput by persisting only domain events (and occasional snapshots) rather than every state change. Redux implements a similar idea through "time‑travel" debugging, allowing the replay of actions to reconstruct state.

CQRS in DDD creates a combined model that aggregates data from multiple aggregates, enabling a single fast query instead of many slow ones. In Redux, this is analogous to multiple reducers updating a shared model using the same actions.

Code Examples

Typical Redux reducers handling posts:

function reducePosts(state, action) {
  switch (action.type) {
    case ADD_POST:
      return { ...state, [action.post.id]: action.post };
    ...
  }
}
function reducePostList(state, action) {
  switch (action.type) {
    case ADD_POST:
      return [...state, action.post.id];
    ...
  }
}
function getPostList(state) {
  // instead of Object.keys(state.post)
  return state.postList;
}

DDD decoupling example without DDD:

class Campaign {
  ...
  startCampaign() {
    product.relabelUnits(advertisedPrice);
  }
}
class Product {
  ...
  relabelUnits(price) {
    units.forEach(unit => unit.relabelPrice(price));
  }
}
class Unit {
  ...
  relabelPrice(price) {
    labeledPrice = price;
  }
}

With DDD, the campaign emits a domain event that units listen to, removing the direct dependency on Product:

class Campaign {
  ...
  startCampaign() {
    emit(new CampaignStarted(..., productId, advertisedPrice));
  }
}
class Unit {
  ...
  onCampaignStarted(event) {
    labeledPrice = event.advertisedPrice;
  }
}

Redux equivalent decoupling using a reducer for units:

function reduceUnit(state, action) {
  switch (action.type) {
    case START_CAMPAIGN:
      return { ...state, labeledPrice: action.advertisedPrice };
    ...
  }
}

Conclusion

Redux and DDD share many architectural similarities and both benefit from the same design principles, despite originating from different abstractions. The main distinction lies in the explicit handling of domain events, a topic that may be explored further.