# What is Domain-Driven Design?

**Domain-driven design** (DDD) is an approach to software design that puts **the business domain** at the center of the system.

Instead of organizing code around technical layers like "controllers" or "repositories", DDD encourages you to model the **real-world processes, rules, and terms** that your users care about.

At its heart, DDD is about one thing: **Make the structure and behavior of your software reflect the way the business actually works.**

## Why Start with the Domain?

Most systems exist to serve a specific domain – logistics, healthcare, education, finance.

But in many applications, the domain logic gets buried under technical concerns. When that happens, software becomes harder to maintain, harder to explain, and harder to evolve.

DDD helps by:

- Focusing on the **language of the domain** (not database tables or HTTP verbs)
- Capturing **business rules** and **processes** explicitly in code
- Making collaboration between developers and domain experts easier

## DDD, CQRS, and Event Sourcing

DDD aligns perfectly with **CQRS** and **Event Sourcing**, because:

- CQRS lets you express **intent and behavior** clearly through commands
- Event Sourcing lets you record **what happened** in domain terms
- Together, they help you build systems that are shaped by **business understanding**, not just technical structure

## It's Not About Technology

DDD isn't a framework or a tool – it's a way of **thinking and modeling**.

You can apply DDD in any language, with or without specific libraries. What matters is the mindset: **Let the domain shape the design.**

## Capturing the Domain Model in Writing

DDD lives or dies by **shared language**. To make the model accessible to everyone on the team – developers, analysts, domain experts – it helps to **write it down in a form they can all read and discuss**.

> **Try it with ESDM**
>
> **[ESDM](https://esdm.io/)** – the **Event-Sourced Domain Modeling language** – captures **aggregates**, **events**, **commands**, **process managers**, **read models**, and **context mappings** as plain YAML. It is **DDD vocabulary on disk** – something you can review, version, and lint, just like code.

**Want to dig deeper into behavior and flow?** See how events trigger reactions and drive read models – in a system that reflects your domain from end to end – in **[Building Event-Driven Applications](/concepts/event-driven-applications)**.