Domain Driven Design at Scale with Vlad Khononov (O'Reilly and Pearson Author)

🎧 New Señors @ Scale Episode

This week, I spoke with Vlad Khononov, software architect, keynote speaker, and author of Learning Domain-Driven Design and Balancing Coupling in Software Design, about what domain-driven design really means when you're building complex systems at scale.

Vlad has spent over two decades helping organizations untangle legacy systems, rebuild failing architectures, and bring clarity to messy business domains. His work spans greenfield systems, enterprise refactors, and the ambiguous environments where most real software actually lives.

In this episode, we cut through the hype around DDD and microservices to focus on the mechanics of bounded contexts, coupling, business alignment, and architectural evolution. We talk about why ubiquitous language reduces project failure, how bounded contexts emerge from social structures rather than diagrams, why most teams misuse aggregates, and how to spot "pain signatures" inside a system and trace them back to unclear domain boundaries.

⚙️ Main Takeaways

1. Ubiquitous language is the core subdomain of DDD

For Vlad, ubiquitous language is the most important part of domain-driven design. It's the common language that bridges the communication gap between business domain experts and software engineers.

• Why it matters: Research shows that most software project failures stem from broken communication. Ubiquitous language addresses this at its root.
• The challenge: You cannot build a ubiquitous language that covers the whole company if the company is doing something non-trivial — it will be too complicated and full of inconsistencies.
• The solution: This is where bounded contexts come in. They define boundaries around smaller ubiquitous languages, creating multiple dialects that are spoken at the company, each with clear boundaries for when and where they apply.

2. Bounded contexts emerge from social structures, not diagrams

Bounded contexts are driven by two things: boundaries of models (or languages) and social decisions — the way people work in your company.

• Team ownership: One bounded context should be implemented by one team only. This ensures knowledge about that particular area of the business domain is handled by a limited group of people with the most efficient communication possible.
• Why boundaries are tricky: Everything that relates to people — how they work, how they communicate — is complex by definition. This makes designing bounded contexts non-trivial, especially as companies grow.
• Evolution over time: As successful startups grow, they add more R&D teams. This means you probably have to redesign the boundaries of bounded contexts over time. You have to pay attention to when that moment comes.

3. Strategic DDD is what you have to do; tactical DDD is what you want to do

DDD techniques can be split into two groups: strategic design and tactical design.

• Tactical design: The "cool stuff" — aggregates, entities, value objects. This is what software engineers want to do.
• Strategic design: The stuff you have to do to be effective when implementing tactical design decisions. This includes understanding the business domain, identifying subdomains, and designing bounded contexts.
• The common mistake: Many teams focus only on tactical patterns (the cool stuff) and don't pay enough attention to strategic techniques. This leads to over-engineered solutions that are simultaneously under-engineered.

4. Most DDD projects are brownfield, not greenfield

Greenfield projects that start with DDD from the get-go are pretty rare. The majority of DDD projects start when a startup's solution grows into a monolith, a "big ball of mud," and then companies ask for training or consultants to help fix it.

• The reality: Even in brownfield projects, DDD typically affects only about 20% of the system.
• Vlad's advice: Don't refactor the whole thing to follow DDD. Focus on those important parts — the core business. The rest, if it works, why touch it? Just make sure you have an explicit boundary around that spaghetti code and the refactored part of the system.

5. Start with pain, not with architecture

When refactoring a monolith to DDD, the first step is to identify the pain.

• Why pain matters: People get used to pain and ignore it. But pain is important — it's how the system tells you what's wrong. Same in software design: we learn to ignore things that annoy us, things that break when we touch them.
• The process: Make sure you know what hurts the most in the system, then ask why it hurts. To answer that question, you have to get into strategic domain-driven design — domain analysis. You have to understand the business domain to identify its subdomains and categorize them.

6. Subdomains come in three types: core, supporting, and generic

When analyzing a business domain, you categorize subdomains into three types:

• Core subdomains: The core competitive advantage — how your company makes money, why customers prefer you over competitors. This is where you invest your efforts because every change there has to be as smooth as possible.
• Supporting subdomains: Something simple, boring, something you have to do to make sure it works. The property of such subdomains is low frequency of changes. If you have pain there, you have to look at how that thing integrates with your core subdomains.
• Generic subdomains: Something where you can use an existing implementation — somebody else has already solved the problem. But you have to make sure there is a boundary between that third-party solution and the rest of your system.

7. Coupling has three dimensions: strength, distance, and volatility

Vlad's model of coupling (from his book Balancing Coupling in Software Design) defines coupling through three dimensions:

• Strength: The amount of knowledge shared across component boundaries. The more knowledge is shared, the more these two components will have to change together.
• Distance: The physical (or social-technical) distance between components. Are they in the same folder, same file, same repository, or different services? The longer the distance, whenever you have to change them together, the more painful that change is going to be.
• Volatility: The rate of changes. If the source of knowledge is volatile (changes frequently), you have a problem. You have to minimize knowledge across bigger distances, or reduce the distance.

The balance: Strength should be inversely proportional to distance, or volatility should be low. That's the balance of coupling.

8. Accidental complexity appears at every layer of a system

Accidental complexity can be everywhere in a system:

• High-level design: Services that are too big (monoliths) or too small (microservices defined by "two pizzas").
• Low-level design: Picking one approach to implement business logic and using it everywhere, which means for some parts of the system it will be fine, for others it won't be effective. Usually, the areas where it's not effective belong to core subdomains.

9. AI makes domain-driven design more important, not less

In the AI era, DDD becomes way more relevant for two reasons:

• Ubiquitous language: How do we interact with AIs nowadays? In natural language. The moment you have that ubiquitous language, your interaction with an LLM is going to be way more efficient. If you're not specific about the business domain, the outcome you get is going to be something that is good for the average company, not something specific to your case.
• Bounded contexts: AI has the same difficulties withstanding complexity as we do. If you're sharing lots of knowledge across big distances and stuff is volatile, the pain is going to be high. If you're able to identify module boundaries using bounded contexts, you have islands of related things that change together, located close to each other. For an LLM with a limited context window, it will be much easier to check dependencies — it's all here.

10. Event storming is the most effective way to synchronize knowledge

Vlad prefers not to have a "golden diagram" that reflects everything. Instead, he keeps things simple so you can keep them in your head, and creates diagrams when needed.

• The problem with documents: If documents are really up to date all the time, then the business is not doing good — you have way too much free time. Usually, diagrams are not up to date. Documents are not up to date. So the source of truth is in the heads of people working on those systems.
• The solution: From time to time, you have to synchronize that knowledge. The most effective way to do it is event storming — a group activity where a group of people brainstorms what they're thinking about a certain area of the business domain and synchronize their understanding of it, synchronize their mental models.

🧠 What I Learned

• Ubiquitous language is not just terminology — it's the bridge between business and engineering that reduces project failure.
• Bounded contexts are as much about social structure as they are about technical boundaries.
• Most teams misuse aggregates because they focus on tactical patterns without understanding the strategic context.
• Pain signatures in a system can be traced back to unclear domain boundaries.
• Subdomains evolve over time — what's core today might be supporting tomorrow.
• Good designs can quietly become counterproductive if you don't watch how the domain evolves.
• Coupling is not inherently bad — it's about balancing strength, distance, and volatility.
• AI and LLMs make DDD more important because they need clear domain vocabulary and modular boundaries to reason about systems.
• Event storming is more effective than documentation for synchronizing mental models.
• The biggest misconception about DDD is that it's over-engineering — but that happens when you ignore strategic design.

💬 Favorite Quotes

"As software engineers, our goal is not to write code, but to solve problems for businesses."
"Ubiquitous language, that's the core subdomain of DDD. That's like the most important part."
"Bounded contexts are basically boundaries around smaller ubiquitous languages."
"If you ignore strategic DDD and you focus on tactical DDD, you will end up with something bad."
"People are getting used to pain. They ignore the pain. But pain is very important. It's how our body tells us what's wrong. Same in software design."
"Coupling means one very basic thing. Whenever you have two components in a system that work together, they're coupled."
"Balance is when these three dimensions are balanced. Either strength is inversely proportional to distance or volatility is low."
"I don't trust documents because in my experience, if the documents are really up to date all the time, then the business is not doing good."
"With AI, I think we are in the same situation. The problem is not everyone realizes how cool domain-driven design is right now."
"The moment you have that ubiquitous language, your interaction with an LLM is going to be way more efficient."

🎯 Also in this Episode

• Why Vlad wrote Learning Domain-Driven Design (it started as an 88-page report)
• When aggregates finally made sense (Vernon's papers on effective aggregate design)
• Why software projects fail (hint: it's about communication)
• The biggest misconception about DDD (focusing only on tactical patterns)
• Common anti-patterns in domain design
• How to begin refactoring a monolith (start with pain, not architecture)
• When companies do DDD without knowing it (Conway's Law in action)
• When DDD fails and lessons learned (Vlad's personal failures)
• Why defining boundaries is hard (it's about people, not just code)
• Microservices, myths, and pain (the "two pizzas" fallacy)
• How Vlad documents architecture (simple diagrams, not golden documents)
• How to enforce ubiquitous language (be a policeman, communicate the why)
• Book recommendations: Scale by Geoffrey West and Composite Structured Design by Glenford Myers

Resources

More from Vlad:
Learning Domain-Driven Design (O'Reilly)
Balancing Coupling in Software Design (Pearson)
Vlad's Website
LinkedIn

🎧 Listen Now

🎧 Spotify
📺 YouTube
🍏 Apple Podcasts

Episode Length: 56 minutes on bounded contexts, coupling, business alignment, and why DDD matters more in the AI era.

If you're building complex systems, leading platform or architecture teams, or struggling with a legacy codebase that keeps pushing back, this episode offers a practical, experience-driven guide to designing systems that scale with the business.

Happy building,
Dan