Navigating DDD and Team Dynamics

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