Domain-Driven Design matters more when AI writes your code
search icon
Type something to search..<br>to navigate<br>to select
ESC to close
Domain-Driven Design matters more when AI writes your code<br>August 20, 2026
Miłosz Smółka<br>Co-founder of Three Dots Labs.<br>Creator of Watermill.<br>Author of Go With The Domain.
Whatever you think of AI coding, the way we build software is changing.<br>Everyone wonders, “What will stay relevant?”<br>All we have is opinions, so here’s mine:<br>most ideas behind Domain-Driven Design are now more relevant than ever, as DDD has never been strictly about code.<br>As we do more coding with agents, we still need to understand the domain, model it well, and work as a team.<br>Let’s see what DDD can still teach us and what AI can’t replace.<br>The usual disclaimer: I write about complex projects maintained over months or years, where teams tend to struggle and where DDD shines.<br>There’s no reason to use advanced patterns in pet projects or CRUDs.<br>What hasn’t changed since 2003<br>Eric Evans published Domain-Driven Design more than two decades ago, but it’s still surprisingly fresh.<br>The book covers many topics, but the main message is that the hard part of software engineering is understanding the problem domain and modeling it well in code.<br>It calls on engineers not to get lost in the technical details and to focus on what they’re solving,<br>because it’s more difficult to get that part right.<br>Instead, the technical talent goes to work on elaborate frameworks, trying to solve domain problems with technology.<br>Learning about and modeling the domain is left to others.<br>Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance.
We now see that the implementation details become less relevant thanks to AI tools.<br>To a degree, you can be productive without a deep knowledge of a programming language or a framework, and it’s easier to move to another tech stack.<br>If you’ve tried using the top coding agents, you’ve probably seen them quickly generate decent code.<br>But knowing high-level software concepts is still essential to guide agents and to decide whether the output makes sense.<br>Most of all, the domain complexity (the business problem you’re solving) is still the hard part .<br>The good news is that coding is easier than ever, so we can focus on these complex problems instead of getting lost in the implementation details.<br>Except, instead of obsessing over building the frameworks (or adding more microservices, or whatever else is a cool trend),<br>we now follow the model benchmarks and optimize our agentic setup to generate better code with less effort.<br>As Evans noted back in 2003, we still try to solve the domain problems with technology.<br>Funnily enough, this time the CEOs also believe it and push us toward it.<br>There’s just one small thing left to figure out: how the thing should work.<br>If someone tells us, we can throw tokens at the implementation and call it a day.<br>And if no one knows, well, maybe an agent could write the plan for us?<br>The domain model isn’t an artifact<br>The foundation of DDD is model-driven design: distilling how the domain works into a model that’s expressed in code.<br>The domain model is an abstract concept, and there’s no one way to represent it.<br>You can use documents, diagrams, and code, but they are all simplifications of how the domain works.<br>An accurate model comes from switching between design and implementation, and applying what you’ve learned over and over.<br>DDD calls this knowledge crunching.<br>You need domain experts (the people who know how the business works), and engineers who are experts at building software.<br>They work together to understand what the software should do and how to implement it.<br>(For example, in an Event Storming session, a workshop where developers and stakeholders map out how the business works with sticky notes.)<br>Figuring out the domain is a team effort and hard work, so it’s tempting to have someone else do it.<br>For example, AI agents are brilliant at research and analysis, and can access your documents, chats, and code.<br>It seems they could create the domain model for you, and then also implement it.<br>But this naive approach misses the point.<br>The value of working on the model is that you (and your team) understand how the domain works .<br>An AI-generated wall of text doesn’t help you figure out the business problem.<br>The agent will just create an impressive artifact no one reads.<br>A domain model isn't an artifact.
The challenge has never been to write a long document on how something could possibly work.<br>More often, software projects fail because of other issues:<br>Engineers work on the wrong thing.<br>No one knows what needs to be done in the first place.<br>The team tries to build everything at once (scope creep).<br>Here’s one trap I’ve fallen into many times.<br>In engineering teams, it’s easy to feel like...