Exploratory Domain Discovery Workshop
Strategic Decision -Making
The Exploratory Domain Discovery(EDD) workshop was designed by Masoud Bahrami.
In a nutshell:
This technique involves a 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 a way of Exploring the Domain in order to Discover the main point and its surrounding context.
More about the guiding principles of Exploratory Domain Discovery
Introduction
To find the right solution, we must first identify the right problem. Problems are interconnected, not isolated. It’s crucial to see the bigger picture, as Professor Steve Hocking said, “the most significant obstacle is the illusion of knowledge.” We need to question our understanding of the problem. Having a clear vision of the solution is like having a map for an unknown journey.
To ensure everyone involved — problem owners and solution providers — shares the same understanding, we need to collaborate on modeling the problem. Tools like EventStorming and Domain Story Telling have become popular in the DDD community for this purpose.
Exploratory Domain Discovery
Exploratory Domain Discovery (EDD) is a collaborative tool that helps us understand a complex problem by exploring its domain. It helps us define the boundaries of the problem and create a shared understanding.
The Main Point of Story
Every story, whether it’s a book, movie, or historical event, relies heavily on context to convey its message. The context is chosen to support the main point of the story. If you want to change the main point, you’ll likely need to change the context as well. This shows that context is closely tied to the main point of the problem we’re trying to solve.
The story of the domain or problem we’re modeling is the case we’re investigating. It contains 99.99% context provided to support its main point. EDD helps us uncover the main point of this story. In the next section, I’ll share some techniques to help you identify and agree on the main point of your domain.
Circularity
We live in a cyclical world. Everything, natural or man-made, seems to repeat in patterns.
For example, with just seven notes (C, D, E, F, G, A, B), we can create incredibly complex music. A group of these seven notes is called an octave. The last note of the octave is the same as the first, creating a cycle. Different musical instruments arrange these seven notes in various ways, but the underlying pattern remains the same.
We can also look at time as an example of a circular pattern. Every day is 24 hours long, and then we start over again. An hour is 60 minutes long, and a minute is 60 seconds long. It’s a cycle that repeats itself.
If we look at these circular patterns, we can see a common theme: repetition. Once we understand the pattern, we can understand the whole cycle.
If our domain or problem is like any other natural phenomenon, it too should have a repeating pattern. By exploring and identifying this pattern, we can uncover the most important aspects of the domain, including its main point.
Payroll System
Let’s take a look at a complex example: a simplified payroll system. Payroll systems are large and complex. I’ll share a real-life example of a conversation between domain experts and developers working on building a payroll system.
Domain Expert:
Hi team. Let’s start by outlining the core functionalities of our payroll system. We need to ensure it accurately calculates gross pay, net pay, and all deductions. It should also generate payslips!, handle tax calculations, and interface with our HR system for employee data.
Software Developer:
Got it. So, does the system need to… calculate pay? And what are deductions?
Domain Expert:
Sure, let’s break it down. Gross pay is the total amount of money an employee earns before any deductions. Net pay is the amount an employee takes home after deductions. Deductions include things like taxes, social security, health insurance, and retirement contributions.
Software Developer:
Okay, I think I got it. So, do we need to calculate the total earnings and then subtract the deductions?
Domain Expert:
Exactly. But it’s more complex than that. We need to consider different pay periods, overtime, bonuses, and various tax regulations. We also need to ensure the system is compliant with labor laws.
Software Developer:
Wow, that’s a lot! So, we’ll need to figure out how to calculate all these things and then store the data somewhere, right?
Domain Expert:
Yes, we’ll need a database to store employee information, pay history, and tax rates. We’ll also need to implement algorithms for calculating gross pay, net pay, and deductions. And don’t forget about the tax engine, which will handle the complex tax calculations.
Software Developer:
A tax engine? What’s that?
Domain Expert:
A tax engine is a software component that calculates taxes based on various factors like income, location, and tax rates. It can be a standalone application or part of a larger payroll system.
Software Developer:
Okay, I see. So, we’ll need to find or build a tax engine. And what about the user interface? How will HR staff interact with the system?
Domain Expert:
A user-friendly interface is crucial. HR staff should be able to easily input employee data, generate reports, and troubleshoot any issues. We’ll need to design a clear and intuitive interface.
Software Developer:
Got it. And what about security? How do we protect sensitive employee data?
Domain Expert:
Great. Now, let’s discuss the different types of employees we need to accommodate full-time, part-time, contract, and temporary. Each type has specific pay and deduction rules.
Software Developer:
Got it. So, we’ll need to have a way to categorize employees based on their type and contract. And we’ll need to adjust the calculations accordingly.
Domain Expert:
Exactly. We’ll also need to consider employee lifecycle events like hiring, promotions, transfers, and terminations. These events can trigger changes in pay, deductions, and benefits.
Software Developer:
So, we’ll need to track employee history and update the system when there’s a change in their status.
Domain Expert:
Yes, that’s right. We’ll need to implement a mechanism to record employee entry and exit dates, as well as any changes in their employment terms. This information will be crucial for accurate payroll processing and generating reports.
Software Developer:
I see. It seems like we’ll need a robust system to manage employee data and track changes over time.
Domain Expert:
Absolutely. A well-designed HR system can help us streamline these processes and ensure data accuracy. We’ll need to integrate our payroll system with the HR system to exchange employee information and updates.
Software Developer:
So, we’ll need to figure out how to connect the two systems and ensure data consistency.
Domain Expert:
Yes, we’ll need to define clear data exchange protocols and error handling mechanisms. This will help us avoid data discrepancies and ensure smooth payroll processing.
As the conversation continues, it can become confusing and easy to misunderstand each other.
EDD uses the Breadth-First Exploration Approach
Exploratory Domain Discovery (EDD) takes a broad approach to exploration, rather than diving deep into a specific detail. This is opposite to our natural tendency to focus on one thing at a time.
The natural tendency of mind in grasping things is depth-first.
EDD involves multiple rounds of exploring the problem to create a model. The problem space is complex and multi-layered. It’s important to maintain the level of exploration in each round of EDD.
Time-Based Value Stream
We start by looking for recurring patterns, often related to time. In the payroll example, we have monthly and weekly payments. Let’s focus on monthly payments.
We’ll choose a specific period, like the second month of the year. If we can model the payroll process for this month, we can likely apply it to other months.
So, what happens to a typical employee in the second month of the year from a payroll perspective?
Domain Expert: An employee works according to their contract. At the end of the month, we use their performance data from another system to calculate their salary based on payroll formulas. We then generate and send them a payslip.
Here, we can see a time-based process. We can visualize this process to better understand it.
Backward Story Telling
To keep the suspense, the main point of a story is often revealed at the end. As software developers, we need to know the main point upfront. In EDD, we start modeling the problem from the end to the beginning, essentially telling the story backward.
So, to tell the story of payroll in the second month of the year, we might start like this:
We end up with a payslip, which is the result of applying payroll formulas to the employee’s performance data for the second month of the year. This performance is based on their employment contract.
As the domain expert tells the story from the highest level, we capture the key domain concepts on sticky notes and place them around a circle.
After that, we add properties to each domain concept.
Then we add the relationship between domain concepts.
To ensure the circle is accurate and captures the problem correctly, we add examples to each sticky note. These examples are also written in reverse order, starting from the end.
We narrate the entire picture from end to start and vice versa. This narrative should align with the backward story we created earlier. First, we narrate without examples, then we narrate again, this time including examples.
Congratulations, we’ve completed the first level of exploration!
EDD’s Building Blocks for the First Level of Exploration
Going to the next level of Exploration
To delve deeper, we need to decide which concepts require further exploration. Should we explore all concepts in detail, or focus on the core ones? In EDD, we prioritize the main and essential concepts, maintaining a high level of abstraction as we go deeper into the problem space. As we saw in the time-based value stream, the circular pattern in our story involves an employee working, completing tasks, and then receiving their salary at the end of the month.
We now have a clue for our next step. We can dive deeper into specific areas, following the same approach as the first level. We start from the end, identify domain concepts, add details to each concept, and provide examples.
Keep an Eye For
As we progress, it’s important to maintain the level of abstraction. In the example, the formula card has a different level of abstraction than the others. The conditions on the cards can be removed and explored in more detail at a later stage.
Boundaries are Emerging
As we delve deeper, we may encounter some boundaries. Don’t worry too much about them for now.
Look for Wanderer Domain Concepts
We call concepts that don’t originate from other concepts in the EDD circles “wanderer concepts.” In the last picture, “insurance” and “tax” appear in the formula but aren’t explicitly defined. We need to make these concepts more explicit.
Consequently, the boundaries of the problem might need to be adjusted.
