Learning Domain-Driven Design, Part 1 with Vlad Khononov

6 snips

Aug 20, 2025

In this enlightening discussion, Vlad Khononov, a seasoned software engineer and author, unravels the complexities of Domain-Driven Design (DDD). He emphasizes the importance of aligning software with business strategies rather than just focusing on code. Vlad explains the roles of subdomains and bounded contexts, helping teams navigate the intricacies of architecture. He also debunks common myths, shares insights on effective communication with domain experts, and discusses prioritizing core business challenges—all while encouraging flexibility in design.

Ask episode

AI Snips

Chapters

Books

Transcript

Episode notes

INSIGHT

DDD Connects Business And Architecture

Domain-driven design helps teams learn the business domain and convert that knowledge into technical decisions.
It gives tools for analyzing business goals and aligning architecture and code to them.

ADVICE

Start With Strategy, Then Code

Prioritize strategic DDD before tactical patterns like aggregates.
Use strategic DDD to shape high-level components, team assignment, and communication needs.

ADVICE

Design For Anticipated Business Change

Learn the business to anticipate reasonable future changes and design modular code.
Use that understanding to keep future refactoring manageable and localized.

Get the Snipd Podcast app to discover more snips from this episode

Get the app

Vlad Khononov, author of Learning Domain-Driven Design, joins us to demystify DDD - focusing on the business first, and the code second.

We unpack what DDD is really trying to help you achieve, why strategic DDD matters most, and how concepts like subdomains, ubiquitous language, and bounded contexts can guide both architecture and team design. Along the way, Vlad shares pragmatic advice for avoiding common misconceptions and making choices that keep you flexible as both your product and understanding evolve.

Topics include:

What DDD is - and the real problem it solves for teams
Strategic vs. tactical DDD (why strategy comes first)
The developer’s role in uncovering business intent and future change
Subdomains: core vs. supporting vs. generic - and why granularity is hard
Ubiquitous language: speaking the business’s language (and making it stick)
Bounded contexts: protecting model integrity and when to widen the scope
One-to-one myths: why subdomains ≠ bounded contexts
Monoliths, modular monoliths, and microservices - choosing for flexibility
Ownership boundaries and deploying multiple artifacts atomically
Integrations and the anti-corruption layer (keeping external models out)
Using the Cynefin framework to reason about core/complicated/supporting work

Vlad also shares hard-won lessons on communicating with domain experts, dealing with uncertainty in core subdomains, and why wider bounded contexts can make early-stage change safer and cheaper.

This episode is packed with practical guidance for anyone trying to align architecture with real business needs - not just patterns.

This is Part 1 of 2. In Part 2 we cover: context mapping, modeling workshops, fit-for-purpose architecture and testing, team boundaries, pragmatic adoption, and AI’s impact on modeling.

Show Links