Learning Domain-Driven Design, Part 2 with Vlad Khononov
In Part 2 of our deep dive into Domain-Driven Design (DDD), Vlad Khononov returns to explore how to apply DDD in the real world.
We move beyond the foundations and into implementation - from context mapping and EventStorming to fit-for-purpose architecture, testing, team design, ownership, pragmatic adoption, and AI’s impact on modeling.
Topics include:
- CQRS in practice
- Bounded contexts and subdomains: boundaries, granularity, and trade-offs
- Context mapping patterns: conformist, ACL, open-host, partnership, separate ways
- EventStorming vs Domain Storytelling
- Architecture patterns: Layered, Hexagonal (Ports & Adapters)
- Implementation choices: Transaction Script, Active Record, Domain Model, Event-Sourced Domain Model
- Tailoring testing strategies to fit your chosen implementation pattern
- Teams and adoption: ownership, safe duplication, where to start, and AI’s role
We wrap with how to adopt DDD without overwhelming your team - focusing on shared understanding, clear ownership, and picking the simplest tools that fit your domain today while keeping tomorrow flexible.
This is Part 2 of a 2-part series. In Part 1 , we covered the foundations: what DDD is for, subdomains and their types, ubiquitous language, bounded contexts, and making flexible architecture decisions.
Show Links
- Vlad Khononov’s Website
- Vlad Khononov on X/Twitter
- Vlad Khononov on BlueSky
- Vlad Khononov on LinkedIn
- Vlad Khononov - Learning Domain-Driven Design
- Vlad Khononov - Balancing Coupling in Software Design
- EventStorming
- Domain Storytelling
- F1 + DDD: All Models are Wrong, Some are Dangerous
- Hexagonal Architecture / Ports and Adapters
- CQRS
- Team Topologies