Domain Discovery: Techniques for Understanding Domains
Domain Discovery is the ongoing process of learning about the business domain. While Event Storming is powerful, it's not the only technique. Staff+ engineers need a toolkit of discovery methods.
TL;DR
| Technique | Best For | Time Investment |
|---|---|---|
| Event Storming | Complex workflows, bounded contexts | 2-4 hours |
| Domain Expert Interviews | Deep understanding, edge cases | 1-2 hours each |
| Domain Storytelling | Process flows, user journeys | 1-2 hours |
| Example Mapping | Acceptance criteria, edge cases | 30-60 min |
| Wardley Mapping | Strategic positioning, evolution | 2-4 hours |
| Impact Mapping | Goals to features | 1-2 hours |
Why Multiple Techniques?
Different techniques reveal different insights:
Technique 1: Domain Expert Interviews
When to Use
- Starting a new project
- Deep-diving into specific areas
- Understanding historical context
- Discovering edge cases
Interview Structure
┌─────────────────────────────────────────────────────────┐
│ DOMAIN EXPERT INTERVIEW TEMPLATE (60 min) │
├─────────────────────────────────────────────────────────┤
│ │
│ 1. CONTEXT (5 min) │
│ • What's your role? │
│ • How long have you worked in this domain? │
│ │
│ 2. PROCESS WALKTHROUGH (20 min) │
│ • Walk me through [specific process] │
│ • What happens first? Then what? │
│ • Who's involved at each step? │
│ │
│ 3. EDGE CASES (15 min) │
│ • What can go wrong? │
│ • What's the weirdest case you've seen? │
│ • What rules are never broken? │
│ │
│ 4. TERMINOLOGY (10 min) │
│ • When you say [term], what exactly does that mean?│
│ • Are there different types of [concept]? │
│ • What's the difference between [A] and [B]? │
│ │
│ 5. PAIN POINTS (10 min) │
│ • What's frustrating about the current process? │
│ • What would make your job easier? │
│ • What questions do you get asked repeatedly? │
│ │
└─────────────────────────────────────────────────────────┘
Powerful Questions
For Process Understanding:
- "Walk me through what happens when a customer [does X]"
- "What's the very first thing that happens?"
- "What has to be true before you can do [Y]?"
- "Who needs to approve this?"
For Edge Cases:
- "What's the strangest case you've ever seen?"
- "What happens when [unusual scenario]?"
- "Has anyone ever tried to [abuse case]?"
- "What rules can never be broken?"
For Terminology:
- "When you say [term], what exactly do you mean?"
- "Is that different from [similar term]?"
- "What would you call [describes concept]?"
- "Are there different types of [concept]?"
For History:
- "Why is it done this way?"
- "Was it always like this?"
- "What changed and why?"
Recording Insights
## Interview Notes: [Expert Name] - [Date]
### Key Terms Discovered
- **Policy Bind**: When coverage becomes active (not just "activate")
- **Endorsement**: Mid-term change to policy (not "amendment")
### Process Insights
1. Quote → Underwriting → Bind → Active
2. Can't bind without underwriting approval
3. Payment must be received within 30 days
### Edge Cases
- Policy can be backdated up to 30 days
- "Flat cancellation" = cancel as if never existed
- Reinstatement possible within 60 days of lapse
### Pain Points
- Manual data entry between systems
- No visibility into underwriting queue
- Refund calculations are error-prone
### Follow-up Questions
- [ ] How does reinstatement affect claims?
- [ ] What triggers automatic underwriting vs manual?
Technique 2: Domain Storytelling
What It Is
A collaborative technique where domain experts tell stories using pictographic language. Created by Stefan Hofer and Henning Schwentner.
The Notation
┌─────────────────────────────────────────────────────────┐
│ DOMAIN STORYTELLING SYMBOLS │
├─────────────────────────────────────────────────────────┤
│ │
│ 👤 Actor (person or system) │
│ │
│ 📄 Work Object (document, data) │
│ │
│ ─────► Activity (verb, numbered) │
│ │
│ 📝 Annotation (clarification) │
│ │
└─────────────────────────────────────────────────────────┘
Example Story
Running a Session
- Invite domain expert and facilitator
- Ask "Tell me the story of [process]"
- Draw as they speak (whiteboard or digital)
- Number activities in sequence
- Clarify ambiguities immediately
- Repeat story back to verify
Benefits Over Event Storming
| Domain Storytelling | Event Storming |
|---|---|
| One expert at a time | Group activity |
| Follows one scenario | Explores all scenarios |
| Linear narrative | Parallel exploration |
| Good for detail | Good for breadth |
Technique 3: Example Mapping
What It Is
A technique for exploring acceptance criteria through concrete examples. Created by Matt Wynne.
The Four Colors
┌─────────────────────────────────────────────────────────┐
│ EXAMPLE MAPPING COLORS │
├─────────────────────────────────────────────────────────┤
│ │
│ 🟨 YELLOW = Story / Feature │
│ "As a customer, I want to place an order" │
│ │
│ 🟦 BLUE = Rule / Acceptance Criterion │
│ "Order total must include tax" │
│ "Free shipping over $50" │
│ │
│ 🟩 GREEN = Example │
│ "Cart: $45, Shipping: $5, Tax: $4.50, Total: $54.50"│
│ │
│ 🟥 RED = Question │
│ "What about international orders?" │
│ │
└─────────────────────────────────────────────────────────┘
Example Map
🟨 Place Order
│
├── 🟦 Order must have at least one item
│ ├── 🟩 Empty cart → Error "Add items first"
│ └── 🟩 Cart with 1 item → Order created
│
├── 🟦 Free shipping over $50
│ ├── 🟩 Cart $49.99 → Shipping $5.99
│ ├── 🟩 Cart $50.00 → Shipping $0.00
│ └── 🟥 What about heavy items?
│
├── 🟦 Tax calculated by state
│ ├── 🟩 CA address → 7.25% tax
│ ├── 🟩 OR address → 0% tax (no sales tax)
│ └── 🟥 What about international?
│
└── 🟦 Payment must succeed
├── 🟩 Valid card → Order confirmed
├── 🟩 Declined card → Error "Payment failed"
└── 🟥 What if payment times out?
When to Use
- Before implementing a feature
- When acceptance criteria are unclear
- To discover edge cases
- To align developers and product
Session Format (30 min)
- State the story (yellow sticky)
- List known rules (blue stickies)
- Add examples for each rule (green stickies)
- Capture questions (red stickies)
- Stop when too many reds (need more discovery)
Technique 4: Wardley Mapping
What It Is
A strategic mapping technique that shows components and their evolution. Created by Simon Wardley.
The Map Structure
Visible to User
↑
┌─────────────────────────────────────────────┐
│ │
│ User Need │
│ │ │
│ ▼ │
│ Component A ──────► Component B │
│ │ │ │
│ ▼ ▼ │
│ Component C Component D │
│ │
└─────────────────────────────────────────────┘
↓
Invisible
Genesis ──► Custom ──► Product ──► Commodity
(Novel) (Built) (Rental) (Utility)
E-Commerce Example
┌─────────────────────────────────────────────────────────┐
│ WARDLEY MAP: E-COMMERCE PLATFORM │
├─────────────────────────────────────────────────────────┤
│ │
│ Visible │ Customer Experience │
│ │ │ │
│ │ ▼ │
│ │ Product Search ────► Recommendations │
│ │ │ │ │
│ │ ▼ ▼ │
│ │ Shopping Cart ◄──── Pricing Engine │
│ │ │ │ │
│ │ ▼ │ │
│ │ Checkout ◄─────────────────┘ │
│ │ │ │
│ │ ▼ │
│ │ Payment ────────────► Inventory │
│ │ │ │ │
│ │ ▼ ▼ │
│ Invisible│ Stripe (API) ◄──── Database │
│ │ │
│ └──────────────────────────────────────────────│
│ Genesis Custom Product Commodity │
│ │
│ Strategic Insight: │
│ • Recommendations = Custom (competitive advantage) │
│ • Pricing Engine = Custom (core subdomain) │
│ • Payment = Commodity (use Stripe) │
│ • Database = Commodity (use managed service) │
│ │
└─────────────────────────────────────────────────────────┘
When to Use
- Strategic planning
- Build vs buy decisions
- Identifying core subdomains
- Technology investment decisions
Connection to DDD
| Wardley Stage | DDD Subdomain | Strategy |
|---|---|---|
| Genesis | Core | Experiment, iterate |
| Custom | Core | Build, invest |
| Product | Supporting | Buy or build |
| Commodity | Generic | Buy, outsource |
Technique 5: Impact Mapping
What It Is
A strategic planning technique that connects goals to deliverables. Created by Gojko Adzic.
The Structure
WHY ──► WHO ──► HOW ──► WHAT
Goal Actors Impacts Deliverables
Example: Increase Order Conversion
When to Use
- Starting a new initiative
- Prioritizing features
- Connecting work to business goals
- Stakeholder alignment
Combining Techniques
Discovery Journey
Technique Selection Matrix
┌─────────────────────────────────────────────────────────┐
│ WHICH TECHNIQUE WHEN? │
├─────────────────────────────────────────────────────────┤
│ │
│ "I don't understand the domain at all" │
│ → Start with Domain Expert Interviews │
│ │
│ "I need to find bounded contexts" │
│ → Event Storming (Big Picture) │
│ │
│ "I need to understand one specific process" │
│ → Domain Storytelling │
│ │
│ "I need to define acceptance criteria" │
│ → Example Mapping │
│ │
│ "I need to make build vs buy decisions" │
│ → Wardley Mapping │
│ │
│ "I need to connect features to business goals" │
│ → Impact Mapping │
│ │
└─────────────────────────────────────────────────────────┘
Continuous Discovery
Discovery isn't a one-time activity:
Weekly Practices
┌─────────────────────────────────────────────────────────┐
│ CONTINUOUS DISCOVERY HABITS │
├─────────────────────────────────────────────────────────┤
│ │
│ DAILY │
│ • Ask "why" when requirements seem odd │
│ • Note unfamiliar terms │
│ • Question assumptions │
│ │
│ WEEKLY │
│ • 30-min domain expert check-in │
│ • Review and update glossary │
│ • Example mapping for upcoming features │
│ │
│ MONTHLY │
│ • Domain storytelling for new processes │
│ • Update context map │
│ • Review bounded context boundaries │
│ │
│ QUARTERLY │
│ • Big picture Event Storming refresh │
│ • Wardley map review │
│ • Strategic alignment check │
│ │
└─────────────────────────────────────────────────────────┘
Staff+ Interview Questions
Q: How do you approach domain discovery on a new project?
A: My approach:
- Stakeholder interviews - Understand goals and constraints
- Domain expert interviews - Learn the vocabulary and processes
- Document review - Existing specs, training materials
- Big Picture Event Storming - Collaborative discovery
- Wardley Mapping - Strategic positioning
- Iterate - Continuous refinement as we learn
Q: How do you handle domain experts who don't have time?
A: I make it easy:
- Short sessions - 30 min instead of 2 hours
- Async options - Review documents, answer questions via Slack
- Show value - Demonstrate how their input improves the product
- Respect their time - Come prepared, don't ask what you could research
- Executive support - Get leadership to prioritize discovery
Q: How do you know when you've done enough discovery?
A: Signs you're ready:
- Can explain the domain to a new team member
- Ubiquitous language is documented and used
- Bounded contexts are identified
- Major edge cases are known
- Team can estimate confidently
Signs you need more:
- Frequent surprises during development
- Disagreements about terminology
- Features that don't fit the model
- Stakeholders say "that's not how it works"
Quick Reference Card
┌─────────────────────────────────────────────────────────┐
│ DOMAIN DISCOVERY QUICK REFERENCE │
├─────────────────────────────────────────────────────────┤
│ │
│ Interviews: Deep understanding, edge cases │
│ Event Storming: Bounded contexts, workflows │
│ Domain Storytelling: Single process, linear flow │
│ Example Mapping: Acceptance criteria, rules │
│ Wardley Mapping: Strategic position, evolution │
│ Impact Mapping: Goals to features │
│ │
│ Key Questions: │
│ • "Walk me through what happens when..." │
│ • "What can go wrong?" │
│ • "When you say [term], what exactly...?" │
│ • "Why is it done this way?" │
│ │
│ Continuous Discovery: │
│ • Daily: Question assumptions │
│ • Weekly: Expert check-ins │
│ • Monthly: Update models │
│ • Quarterly: Strategic review │
│ │
└─────────────────────────────────────────────────────────┘
Next Steps
- Strategic Decisions - Framework for architectural choices
- Event Storming - Deep dive into the technique
- Bounded Contexts - Applying discovery insights