Explore the domain to discover the point.
Exploratory Domain Discovery (EDD) is yet another collaborative modeling and design technique, but it’s a powerful one.
It helps teams align around the complex domain they’re working with and builds a shared understanding early. It gives you a model that doesn’t just describe how things work, it can back your strategic decision-making.
Whether you’re designing a product, structuring teams, or architecting services, EDD helps you surface what truly matters.
In a Nutshell
“Exploratory Domain Discovery involves backward-stepping (by retracing our steps) and breadth-first exploration of a domain. By empirically investigating the domain and narrating its history in reverse chronological order, we can uncover circular patterns and identify the core (main) concept.”
This method is about exploring the domain to discover the main point, and the context that surrounds it.
Why It Exists
Most domains are messy. Conversations are scattered, and decision-making is often based on assumptions. Stakeholders use different language. And before long, you’re building features without really knowing what you’re solving.
EDD exists to bring clarity, not by starting from inputs, but by starting from what success looks like and working backward.
EDD’s Philosophy
- Domains often follow cyclical patterns
- Domains have recurring structures
- Most of the domain’s information is just context for one main idea
- That main point drives everything else
Rather than modeling from the middle out, EDD turns the process around. It puts the desired end state at the center, and asks: What is the journey that leads to this outcome? What are the repeating structures? What is the concept that explains the rest?
What Exploratory Domain Discovery Offers
- Brings the right people together early
- Encourages collaboration around the problem, not just the solution
- Builds a shared visualization of the domain
- Surfaces cyclical or circular patterns in how the domain works
- Focuses on identifying the core concept that gives context to everything else
- Models from the desired end state back to the beginning
- Maintains the right abstraction level during each phase
- Builds shared understanding through concrete examples
- Encourages collective ownership of the emerging model
EDD’s Golden Rules
- Start from the end goal
Explicitly begin from the desired outcomes, the state you want to reach. - Keep the abstraction level steady in each round
Don’t mix low-level detail with high-level structure in the same conversation.
Key Elements of Exploratory Domain Discovery
Domain Concept
A significant idea or object in the business context.
Example: Hotel Voucher, Booked Room, Hotel Availability, Room Pricing
Example
A concrete, real-world scenario to illustrate a domain concept.
Example: A printed or emailed hotel voucher
Relationship
An inherent connection between domain concepts.
Example: How a legal document relates to a finalized hotel booking
Questions and Discussions
All questions are welcomed and documented to deepen shared understanding.
Example: What happens if the guest cancels? How should we apply the policy?
Business Rule
A constraint or condition that governs domain concepts.
Example: A room cannot be booked unless it’s available. Children must have a guardian.
Main Point (Core Concept)
The central idea that everything else supports.
Example: Hotel Room is the focal point around which all other concepts revolve.
The EDD Methodology
Step 1: Identify Cyclical Patterns
Look for loops and recurring structures in time. These often signal what really matters in your domain.
Examples:
- Financial periods
- Daily bank closures
- Hotel contracts
- Employee payroll cycles
- Temporary or seasonal service closures
These recurring structures are hints, they help you trace back to your domain’s main point.
Step 2: Work Backwards From the Desired End
Once you identify the target outcome, retrace the steps that lead to it:
- Start from the desired end state
- Keep a consistent level of abstraction
- Talk and document your shared exploration
- Capture the sequence of key domain concepts
- Map the relationships between them
- Define essential properties for each concept
- Add concrete examples to illustrate each idea
- Narrate the story from end to beginning, and again from beginning to end
- Go deeper in the next level of abstraction only when necessary
Should You Model Everything in the First Cycle?
No. Resist the urge to fully elaborate every detail up front.
Instead:
- Prioritize the concepts that directly relate to the core cyclical pattern
- Leave the rest for future rounds of exploration
- Build understanding gradually, with focus
When to Use Exploratory Domain Discovery
- When entering an ambiguous or unfamiliar domain
- When stakeholders and tech teams speak different “languages”
- When complexity and uncertainty are high
- When your architecture needs to reflect real business structure
- When forming new teams or defining service boundaries
- When conventional modeling feels disconnected from actual goals
Final Thought
You don’t need to model everything, just what matters.
And you don’t have to do it alone.
Exploratory Domain Discovery is a way to explore the problem space with others, discover the main point, and make better decisions, together.