#48 DDD Series: From Business Talk to Software Requirements
Every software project starts with confusing business talks and big promises. Here is how to make sense of them before writing a single line of code - lessons from 13 years in IT industry.
When we build software, we are always working in what we call a “domain” - basically, the business area we are focusing on. Think of it like this:
E-commerce. This includes everything about online shopping, from showing products and processing orders to handling payments and more.
Taxes. Covering stuff like income tax, and business tax, making sure people follow tax rules, and working with tax policies.
Healthcare. Managing patient info, scheduling doctor visits, keeping medical records, handling prescriptions, and so on.
Education. Involves things like tracking homework, running online learning platforms, managing student sign-ups, and grading.
Logistics. Managing warehouses, moving stuff around, keeping track of inventory, finding the best delivery routes, and scheduling deliveries.
As you can see, it all depends on what industry you are in. Here is the interesting part - businesses in the same field often look pretty similar. They follow common patterns that show up again and again. But don't be fooled - even if they look alike, they never work exactly the same way.
That is why we need to really dig into understanding our business domain every time we build something new - or rebuild a legacy system.
Our Business Domain - Fitness
So, imagine we have been hired to build an app that handles everything you can think of for a fitness studio. Sounds exciting, right?
Now, here is the thing - we can't just lock ourselves away, try to build every possible feature, and come back two years later with a finished product. That is usually a recipe for disaster - either we run out of money or end up with something nobody wants to use! Instead, we need to focus on creating a system that actually helps our customers and covers the most important stuff.
Great, but how do we figure out what these important processes are? Sure, we can use fancy techniques like Event Storming or Domain Storytelling. We will get different people together for workshops, brainstorm ideas, and map out how everything should flow.
But here is a secret - it usually starts way before that. It begins with ideas that come to you before you even think about planning workshops. Usually, you are invited to a meeting where someone tells you something like this:
“We want to build a SaaS app that any fitness studio can use. It will handle everything - from making the first offer to planning diets.”
“We need to create and promote offers to our customers. When someone wants to join or renew their membership, they will sign a contract.”
“After they sign the contract, they will get a pass to access the studio.”
“And when their pass expires, we need to be able to offer them a new contract.”
“Oh, and we need some reports - maybe just showing how many passes we have sold to start with.”
And a hundred other inputs like these.
Now, you might feel overwhelmed. But actually, you are lucky - I have been in situations where teams were just told “Just make it like app XYZ!” and that was it.
That is what I call a red flag.
So why am I happy with getting this surface-level info without all the details? Because the details will come later in those workshops you will organize.
Let's break down what we have learned and how we can use it for our first workshops:
Starting with the first statement: “We want to build a SaaS app that any fitness studio can use...”
This tells us something important - we are probably building a SaaS (Software as a Service) app for fitness studios. It is technical stuff, but it shows the business model - how we plan to make money. Write this down - you will want to talk about it with your team after the workshops.
Why? Sometimes there might be better ways to do things, and part of your job is speaking up if you see a better approach.
Moving on to the next part: “We need to create and promote offers to our customers...”
Now we are getting our first real requirements, which we will dig into during workshops. Someone needs to create offers and show them to both new and existing customers. If someone likes what they see, they will sign a contract. This gives us a framework for planning our workshops and knowing what to focus on. Some questions that pop up:
Will we build the entire offer system in our app?
How will people see these offers? Through emails? In the app?
What if someone wants a discount?
Do they sign the contract online or at the studio?
These are all things to figure out when you meet with the domain experts and decision-makers. It is great that we are already thinking of these questions - write them down for later.
Looking at the next piece: “After they sign the contract...”
We can now see five main business processes:
Creating offers
Promoting offers
Preparing contracts
Signing contracts
Registering passes
This last step - registering passes - happens after someone signs a contract. More questions to think about:
How do customers get their passes?
Can they get them different ways - like in person, by email, or in the mail?
These are all good things to bring up in future discussions.
Let's look at managing existing customers: “And when their pass expires, we need to be able to offer them a new contract…”
Aha! So when someone's pass is about to run out, we send them a new contract offer. This brings up more questions:
What exactly counts as an expired pass?
Should we make offers before passes expire?
Should we include special renewal discounts?
Could some contracts renew automatically?
Look at how much we have learned from just a short conversation. And this is just what we have thought of - imagine what will come up when you get everyone together to brainstorm.
The last part talks about reports: “Oh, and we need some reports…”
We want to track how many passes we are selling. This is another area to focus on. We should definitely check with the fitness studios about what reports they actually need. If nobody has asked them yet, that is a great question for the workshops: “Why haven't we talked to the people who will actually use this?”
Summary
This early analysis is valuable, and I really recommend doing it. It helps you:
Get a head start on understanding what you are building
Spot potential problems before they become real headaches
Show up to workshops prepared with smart questions
Save time by focusing on what really matters
When you break down conversations like this, you are not just collecting requirements but also starting to see the bigger picture of how everything fits together. Plus, it makes those upcoming workshops way more productive because you have already done some homework.
Next time you are starting a new project, try spending just an hour or two breaking down those initial conversations. You might be surprised at how many important questions and insights pop up, and your team will definitely appreciate having a clearer starting point for those deeper discussions.
Good software starts with good understanding, and every little bit of preparation helps build that understanding stronger.