Introduction
One of the crucial principles of Exploratory Domain Discovery is the concept of Working Backwards. In domains with Cyclic Patterns and Time-Based Value Streams, we begin our exploration from the desired end goal and trace the path backward. This approach allows us to see the connections between concepts more clearly, transforming what once seemed like scattered dots into a cohesive, well-structured map of the domain. By retracing the journey, each step reveals how the concepts interconnect, and the path to the desired outcome unfolds with clarity and purpose.
In this article, I’ll delve into the importance of the Working Backwards approach, explaining how it enhances domain discovery and helps build a more precise and effective model.

Time Travel
Imagine you’re about to embark on a long, dangerous journey with no clear destination. With each step, you wish you knew the next step, the pitfalls in the path, and the difficulty. You wish you had a broad vision that could tell you whether or not you’re on the right path. This is precisely why we use the ‘Working Backwards’ approach. It’s like having a map of that journey, but instead of reading it from start to finish, you read it from the end back to the beginning.
Now, imagine having a time machine that allows us to jump to the future—the moment we’ve achieved our goal. We want to go forward in time, as Stephen Hawking’s parties haven’t come true yet, so we can’t travel back in time!

You’re on it and travel the time axis towards future until you reach your desired goal. You can see the journey, it’s stops and connect them from, draw a journey path on your map for it.

Software development is a learning process. The process is a long journey full of details. The Evil is in detail. So be careful. Also, notice about the consequences of different narrating of this journey.
Software development is a learning process.
Alberto Brandolini
Exploratory Domain Discovery’s Time-Travel Machine
Exploratory Domain Discovery quipped with a simple but powerful time-travel machine. After discovering domain cyclic patterns and time-based value streams, for each one, we start asking a simple question:
- What is the end desired goal here?
If we go forward and able to see the end of this product, what would it be?
- or a more fun, good, desired and simpler question:
- What we want it to be?
Let’s go back to the accounting system. We’ve identified a financial year as a domain cyclic patterns with a repeating behavior in its nature. Asking yourself the simple questions mentioned above. Yes you’re right. The answer is really simpler than the question → A Journal

Congratulations! You’ve identified your firs Domain Concept in EDD. Put it in a sticky note and put up them on the wall!

Working Backwards
Sorry 🙇♂️ But I don’t have any time-travel in EDD. My promises is Brocken.
But don’t worry. I equipped EDD with a more powerful and simple tool. Before starting the journey-learning long journey- you can imaging, draw and frame your desired journey from the end desired goal.
This approach lets you map out the entire journey from the point where you want to be, all the way back to where you are now.
Even without a time machine, by working backwards, you can clearly see the path that leads to your goal. You can identify key milestones and potential pitfalls, giving you foresight and clarity. Instead of getting lost in the details, you start with a vision of the end result, and everything along the way becomes clearer.
This method lets you anticipate challenges, identify the essential steps, and avoid unnecessary detours. It shifts your thinking from simply reacting to problems as they arise to proactively planning your journey with purpose and foresight. In this way, you can approach domain discovery with a strong sense of direction, knowing exactly where you want to go and how to get there.
Accounting Example
Let’s continue with the accounting example. We’ve already identified that the end desired stop is the Financial Journal—the ultimate goal of this domain journey.
In EDD, we start from this Domain Concept and work our way backward, retracing the steps until we reach the concept of the Financial Year—the foundational building block of this domain.
So, we begin at the Financial Journal. This is where all the financial transactions are recorded. But how do we get to the Financial Journal? What must exist before it?
We see that before a financial transaction can be journaled, it needs to be captured in the context of the Financial Transaction itself. These transactions are the core events that ultimately get logged into the Financial Journal.
Now, before we can capture a financial transaction, it needs to have some structure or context, such as the Subledger Account.
As we work backward, we find that all of this is part of a larger cyclical structure—something that repeats every year. The starting point of this entire journey is the Financial Year. The Financial Year sets the framework for accounting periods, dictating when transactions are recorded, processed, and reported.
So, in summary, we move backward through the domain like this:
- Financial Year → the cycle that defines the periods within which all financial activities take place.
- Subledger Account → where financial transactions are categorized before being recorded.
- Financial Transaction → the core events that will be logged.
- Financial Journal → the final destination where transactions are officially recorded for reporting.

This is how EDD works: by starting at the end goal—the Financial Journal—and tracing the journey backward to its origins. Working backward gives us a clear map of the domain, showing us how all the pieces connect and interact, from the highest level (the Financial Year) to the granular details (the Financial Journal).
Connecting the Dots

As Steve Jobs famously said, “You cannot connect the dots forward; you can only connect them backward.” This perfectly aligns with the essence of the Working Backwards approach in Exploratory Domain Discovery. When you try to connect the dots forward, the path can seem unclear, filled with uncertainties and unknowns. But when you start from the end goal and work backward, the connections become more apparent, and the dots fall into place.
In the context of our accounting example, if we tried to map out the journey forward—starting from the Financial Year and working through to the Financial Journal—it might be easy to miss key milestones or overlook essential concepts. However, by beginning at the Financial Journal and retracing our steps, we can clearly see how each concept leads to the next, how the Subledger Account feeds into the Financial Transaction, and how all of this fits into the framework of the Financial Year.
By connecting the dots backward, we gain a much clearer and more structured view of the domain. This approach helps us understand not just where we are going, but how everything connects and what needs to happen along the way to reach our destination. In this sense, we are truly connecting the dots—not in a linear, forward-thinking way, but in a way that makes the entire journey more comprehensible and deliberate.
In Exploratory Domain Discovery, starting from the end goal and working backward allows the connections to become clearer, transforming what once seemed like scattered dots into a cohesive, well-structured map of the domain. By retracing the journey, each step reveals how the concepts interconnect, and the path to the desired outcome unfolds with clarity and purpose.
[…] 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 […]