Why AI is the Third Coming of Domain-Driven Design

subscribe to the newsletter: https://deararchitects.xyzBalancing Coupling in Software Design: https://amzn.to/4rotZlzLearning Domain-Driven Design: https://amzn.to/4tGQvb2Most architects have been thinking about coupling the wrong way for years. Not as something to understand and design deliberately but as something to eliminate. That misunderstanding is behind most of the distributed monolith disasters of the microservices era.In this episode, Vlad, author of Balancing Coupling in Software Design, shares what he learned after building a textbook distributed monolith while following best practices to the letter. We dig into why coupling is unavoidable, what the three dimensions of coupling actually are, and why strategic DDD consistently beats tactical DDD for large systems.But the conversation takes an unexpected turn: Vlad argues AI is the third coming of Domain-Driven Design. When you prompt an AI in natural language, ambiguous domain models don't just slow your team down — they get baked silently into generated code. The same discipline that makes systems evolvable turns out to be the foundation for working effectively with AI.0:00 Intro & guest welcome1:00 Why modeling is the foundation of good software design2:45 Rethinking coupling — it's not what you think8:00 How microservices created the distributed monolith trap14:00 The real cost of splitting without fixing the design19:00 Why pain is your best architectural signal23:00 Domain-Driven Design has a reputation problem28:00 Strategic DDD vs tactical DDD — what actually matters33:00 How to approach a brownfield system37:00 Subdomains: the hardest part of DDD nobody talks about enough41:00 Bounded contexts and why less is more for startups46:00 AI is the third coming of Domain-Driven Design52:00 Teaching DDD to an LLM — what Vlad actually tried55:00 Working code is no longer the challenge. Evolvable code is.1:00:00 What Vlad would change in his book1:07:00 What's next