The First Flow

Introduction

To solve complex problems, we need to really understand them first. This is very important in fields like software development, improving how businesses work, and making plans for the future. Exploratory Domain Discovery is a technique that helps with this. It uses repeating domain circular patterns to guide the process of understanding a problem. This article shows you how EDD works.

Spoil 👀⌚ the first round of Exploratory Domain Discovery should take about 6-7 minutes!

The EDD Process

The EDD process begins by identifying circular patterns or cycles within the domain. These patterns form the foundation for the entire exploration. Think of the monthly cycle of work, pay calculation, and receiving a payslip in a payroll system—this is the kind of cyclical behavior that EDD seeks to uncover. Once a circular pattern is identified, the team starts with the end goal or desired outcome of that cycle and works backward. This backward exploration is the heart of EDD.

Identifying Domain Concepts

As the team moves backward, they identify the key domain concepts involved in the process. These concepts are recorded on sticky notes, creating a visual representation of the domain. The color is not important, just use the same color for all domain concepts!

Note: ⚠️The name of a domain concept. As mentioned earlier in the building blocks of EDD article a domain concept should not be a verb or an action.

For instance, in our payroll example, starting with the end result of Payslip Received might lead to identifying concepts like Payslip, Payroll Formula, Work Hours, Recruitment Order and Employee, as we trace the steps back.

Establishing Relationships Between Concepts

With these key concepts identified, the next step is to establish the relationships between them. Critically, this is also done working backward from the end goal. This backward relationship mapping clarifies the dependencies and the flow of information within the domain.

Adding Properties to Each Concept

After defining the relationships, the team adds properties or attributes to each domain concept to provide more detail and context.

Don’t! ⚠️⚡ Don’t add to much properties under each domain concept. Just add 4-5 properties-at last.

⚠️This is the first time we dare to go deeper than the level of abstraction. Details are emerging, so watch out!

Adding Examples

Finally, concrete examples are added to each concept, again working backward. These examples ground the abstract concepts in real-world scenarios, making the model more tangible and relatable.

Narrate: Exploring the Domain Backward and Forward

Backward

In the EDD process, as the team begins to explore the domain, one of the people in the room starts by narrating the story from the end to the start. This backward narration approach allows the group to focus on the end result first and trace the path backward to uncover the underlying processes and concepts that lead to it. This method ensures that everyone has a clear view of the desired outcome and how it connects to the earlier stages of the cycle.

As the story unfolds backward, the narrator continues to introduce the key domain concepts—concepts like Payslip, Payroll Formula, Work Hours, Recruitment Order, and Employee—and the relationships between them, all while sticking to the backward progression.

Then, real-world examples are woven into the narrative, helping ground these concepts in practical, everyday scenarios. For example, the narrator may explain how Work Hours are logged by employees, leading to the calculation of Payroll Formula and how this ultimately results in the generation of the Payslip These examples help bring the abstract concepts to life, ensuring that the team fully understands their relevance in the context of the larger process.

Forward

After this backward exploration, the team then shifts to narrate the story from the start to the end. This forward narration allows the group to tie together the relationships between the concepts and verify that the cycle makes sense from both perspectives. This step ensures that the team understands not just how the pieces fit together, but also how they flow and interact in a real-world application.

The benefit of this dual narration process—backward and forward—is that it creates a consistent and holistic story. By listening to the story from both directions, everyone in the room can fully capture and understand the domain concepts, their interconnections, and how they play out in real-world examples. This approach ensures that the exploration is thorough, engaging, and deeply insightful, making it easier for the team to identify gaps, solve problems, and improve the system being studied.

Ultimately

Ultimately, through this process of narrating the story backward and forward, the team not only develops a comprehensive understanding of the domain but also ensures that the concepts and examples remain consistent and grounded in reality throughout the exploration. This narrative approach strengthens the connection between abstract theory and practical application, resulting in a clear, shared vision of the system or problem at hand.