The Heart of Exploratory Domain Discovery
A New Lens on Modelling Complex Domains with Exploratory Domain Discovery
The previous article briefly introduced Exploratory Domain Discovery` Workshops.
The question is: What sets Exploratory Domain Discovery apart from other collaborative modeling and design tools like EventStorming or Domain Storytelling? Given the maturity and popularity of these tools, why do we need a new approach?
Why do we need Exploratory Domain Discovery when we already have effective tools like EventStorming and Domain Storytelling? What makes EDD unique?
What EDD Shares with Other Collaborative Modeling Tools?
As another tools under collaborative modelling umbrella, Exploratory Domain Discovery has a lot in common wither a dozen other tools.
It starts with a simple, to-down approach. EDD like other tools starts from end by putting the focus on abstraction. By merging people, It allows for flexible decision-making and encourages collaboration among team members. The tool uses basic building blocks to create complex models.
Exploratory Domain Discovery Philosophy
While collaborative modelling tools share common ideas and practices in their essence, each one has its own philosophy and so address a problem from different perspective. some of them also address a different problem.
Exploratory Domain Discovery aims to make strategic decisions by identifying the core idea(main point) of a domain.
EDD is based on this philosophy principles:
- Domains often follow cyclical patterns.
- Domains have recurring patterns.
- Most of a domain’s information is context for a single, main idea.
- Domains often follow cyclical patterns.
- The Main Point is the main driver of its context.
The Dance Between Authors and Audiences
When audiences engage with a story, they’re looking for the main point or message. To guide readers towards this understanding, authors often build suspense by starting with context and revealing the main point later.
Every software has a story. The story is the domain of that software. So every software or every domain has a main point, covered by a vast majority of information serving as its context. As software developers, We are the authors of the story not the audiences. So it is crucial to start with the main point and provide and design the context based on the main idea.
As software developers, we’re not simply reading a story; we’re writing it. It’s essential to begin with the core purpose of the software and then design the features and functionalities to support that purpose.
But in reality, in order to get the domain or to catch it, we start learning the domain by playing as the audience, I mean in the beginning domain experts act as the author. But we should upgrade our role as soon as possible. Domain experts as the authors start telling the story by giving the context.
We’re not passive observers of software; we’re active participants in its creation. We must start by defining the main objective of the software and then develop the supporting elements to achieve that objective.
The Distinctive Features of Exploratory Domain Discovery
Also all collaborative modeling approaches share a core essence. However, Exploratory Domain Discovery offers a unique twist by:
🔵 Explicitly starting from the end: EDD begins by focusing on the desired outcome, ensuring clarity and alignment.
🔵 Explicitly identifying the Main Point of the domain: EDD helps pinpoint the core problem or opportunity, streamlining efforts.
🔵 it explicitly put as much as emphasis on keep the level of abstraction in each round-fight: in the early stages, I referred to this approach as Breadth-First Exploration
🔵 Explicitly identifying circularity pattern(s) in problem space
🔵 Explicitly emphasizing TIMED-BASED VALUE STREAMS: EDD prioritizes the flow of value over time, ensuring a customer-centric approach.
I’ll explore these topics further in my next few articles. Stay tuned for more!
