What is Domain-Driven Design?

Origin

Eric Evans published Domain-Driven Design: Tackling Complexity in the Heart of Software in 2003, distilling lessons from years of building complex enterprise systems in insurance and logistics. The "blue book," as engineers came to call it, did not invent the underlying techniques — object-oriented modeling, separation of concerns — but it named the patterns that made software resilient against the very real complexity of real businesses. A second wave of DDD writing in the 2010s (Vaughn Vernon, Greg Young, Alberto Brandolini) extended the ideas with practical workshops like Event Storming.

Ubiquitous language

The single most under-rated DDD idea is ubiquitous language. Engineers and domain experts agree on one vocabulary for the parts of the business that matter — and that vocabulary lives in the code, in the tests, in the diagrams, in the standup conversation, identically. When an underwriter says "endorsement," the class is called Endorsement, not PolicyAmendment. When a trader says "fill," the table is called fills, not order_executions. The discipline sounds trivial until you have worked on a system where it failed; the cost of disagreement compounds for years.

Bounded contexts

The second big idea is that "the same word means different things in different parts of the business, and that is fine — but you have to draw the line on a map." A Customer in the billing context has a payment method and a credit history. A Customer in the support context has a tier and an SLA. A Customer in the marketing context has a segment and a campaign membership. Treating them as one mega-Customer object is how teams end up with a 4,000-line class that nobody understands. Bounded contexts make the seams explicit: each subdomain owns its own Customer model, and translations happen at the edges.

Strategic vs tactical DDD

DDD has two halves that often get conflated. Strategic DDD is the map-making work: identifying subdomains, drawing bounded contexts, deciding which contexts are core (the company's competitive advantage), which are supporting, and which can be bought off the shelf. Tactical DDD is the in-code patterns: entities, value objects, aggregates, repositories, domain events, application services. A team can do excellent strategic DDD and write the tactical code in plain Rails or Express — and they will still get most of the value. A team that obsesses over tactical patterns without first doing the strategic work usually builds something elegant in the small and incoherent in the large.

At QUANT LAB

Our custom software projects start with a discovery phase that is essentially compressed DDD — we sit with the people doing the work, write down the words they use, sketch the actual flow of an order, a claim, a deal, and only then put a domain model on the whiteboard. The result is that the code that ships uses the same words the business uses, which makes onboarding new engineers a matter of weeks rather than months.

DDD pairs especially well with event sourcing and CQRS in domains where the audit trail matters — insurance, fintech, healthcare. For simpler domains we keep the strategic ideas and the language discipline and skip the heavier tactical patterns. Book a call if you have a complex business domain and want a clean model to start from.