Skip to content

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.

ESDM – 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? Next, we'll explore how commands trigger events and how those events drive projections – in a system that reflects your domain from end to end. See Follow our walkthrough of an event-driven architecture.