Menelaos Vergis<br>Linkedin<br>GitHub<br>YouTube<br>X.com<br>Why Domain-Driven Design Is a Great Fit for Coding with Claude<br>If an LLM is only as good as the context you give it, then the discipline that produces the best context wins. That discipline is Domain-Driven Design

Jul 14, 2026

TL;DR<br>An LLM's output is bounded by the quality of the context it receives. DDD is a discipline for producing explicit, named, unambiguous context .

The artifacts DDD makes you create, such as a shared vocabulary, clear boundaries, invariants stated out loud, are exactly what an AI coding assistant is starving for. The glossary you'd write for a human teammate is a great system prompt.

The catch: an LLM left to its own defaults produces the opposite of DDD; anemic CRUD, generic names, blurred boundaries, over-engineered patterns. You have to steer.

Use the cheap parts of DDD (language + behavior-rich models) everywhere; adopt the expensive parts only when the domain earns them.

What DDD actually is (the 60-second version)<br>Domain-Driven Design isn't a framework or a folder layout. It's a bet: in complex software, the hard part is understanding the domain, not the technology. So you put a model of the domain at the center: a deliberately simplified, purpose-built view. You express it in a language shared by developers and domain experts, and you make the code mirror that model directly.<br>It has two halves. Strategic design is the big-picture stuff: a shared vocabulary (the Ubiquitous Language), and bounded contexts, the boundaries within which a model and its language stay consistent. Tactical design is the building blocks inside a boundary: entities, value objects, aggregates, domain events.<br>One pitfall to watch for, and the one .NET developers hit most: the anemic model . It's an object that's just a bag of public getters and setters, with all the real rules exiled to separate "service" classes. DDD's instinct runs the other way: push behavior into the object that owns the data, so its rules are guarded where they live.<br>That's the whole foundation. Now here's why it pairs so well with an AI.<br>Why DDD fits LLM-assisted development<br>An LLM's output quality is bounded by the quality of the context it's given. DDD is a discipline for manufacturing exactly that kind of context. Every DDD artifact doubles as prompt material.<br>A quick example to make this concrete, and one I'll reuse throughout. Imagine a live-event ticketing app. The team agrees on precise words: a hold is a temporary, unpaid grab on some seats; a booking is what that hold becomes once it has been paid for; and an unpaid hold expires after a few minutes so the seats go back on sale. Three plain words, used the same way by everyone. Keep them in mind, because every point below leans on them.<br>Four concrete ways this shows up:<br>1. Ubiquitous Language ↔ prompt context. The single biggest lever on AI code quality is unambiguous vocabulary. Because the team fixed those words, the model generates SeatHold.Expire() instead of guessing at Reservation.Update(). The word "expire" was chosen deliberately over "cancel," so nobody, human or machine, has to guess which verb means what. The glossary you write for the team is the same glossary the AI needs. You were going to write it for humans anyway, so now it pays double.<br>2. Bounded contexts ↔ scoping the session. LLMs degrade when you dump an entire system into the prompt; attention spreads thin and boundaries blur. A bounded context is a natural unit of work: "we're in the Ticketing context today; here's its language and its rules; ignore Payments." That maps cleanly onto one focused session or one subagent, which is exactly how you get the model to stay on-target.<br>3. Behavior-rich models ↔ code the AI can't silently corrupt. When invariants live inside the object (SeatHold.Confirm() checks "must be active, must not be expired"), there's one guarded doorway. When they're scattered across services (the anemic style), any generated line can reach in and set Status = "Confirmed", skipping every rule. Concentrating rules in one place shrinks the surface where an AI (or any teammate) can quietly break things.<br>4. Tests-as-spec ↔ an executable contract. DDD's invariants translate directly into tests: "cannot confirm an expired hold." Have the assistant write those tests first, and you've given it an executable definition of "correct" to code against, which is far more reliable than prose alone.<br>The through-line: DDD forces you to make the domain explicit, and explicit is precisely what a language model can act on.<br>The traps hiding in Claude + DDD<br>Here's the honest part. An LLM's default behavior is the enemy of good DDD, because the training data is full of the patterns DDD warns against. Know these before you start:<br>It defaults to anemic CRUD. Ask for "a SeatHold class" cold and you'll often get public getters/setters plus a SeatHoldService holding the logic, the exact anti-pattern. You have to explicitly ask for behavior on the object and...