Oh boy, here we go again.

Every time we build software, we operate in an area called a domain. It is something that describes our business. It can be:

• E-commerce - this domain can include online shopping, product catalogue, order processing, payments and many other smaller parts
• Taxes - in this domain we can find areas like income tax, corporate tax, tax compliance or tax policy
• Healthcare - this can include areas such as patient management, appointment scheduling, medical records, prescription management, etc.
• Education - areas such as assignment tracking, learning platforms, student enrolment, grading, etc.
• Logistics - things like warehousing, transportation, inventory management, route optimisation or delivery scheduling

As you can see, it all depends on the sector in which you operate. Often, businesses operating in the same sector are similar - that is, they are represented by standard, basic business models or types that represent core aspects of any business or industry. Such representations are called archetypes - more on this in the chapter where we focus on subdomains. This does not mean, however, that all these parts work in the same way.

And that's something we need to address in our analysis of a business domain, every time we build (or rebuild) the system.

Our business domain - Fitness Studio

We are hired to build an application that will be responsible for handling all possible processes that you can imagine when you think about a fitness studio.

Of course, it is not possible to close the door, implement every possible business process we can think of and release our application in 2 years (such an approach usually ends in disaster - quite often we run out of money or no one wants to use it). Instead, we should think about the MVP that would cover the minimum of critical processes for our business that can be released (and useful) to our potential customers.

Ok, great. But… how do we find these processes? Surely techniques like Event Storming or Domain Storytelling will help. We gather different people for a series of workshops and there we brainstorm the ideas and think about the flow.

Yes, this is a step you will need sooner or later. But in practice it all starts somewhere else. It starts with some ideas that are presented to you before you even think of planning any workshops. Usually you are invited to a meeting or a conversation where the idea is presented to you in a form similar to the one below:

We want to build a SaaS application that can be used by any fitness studio. It will cover everything you can think of, from the initial offer to diet planning.

We want to prepare offers and promote them to our potential and existing customers. If someone is interested in joining or renewing their membership, the contract should be signed.

Once the contract has been signed, the client will be issued with a pass allowing access to the studio.

Of course, when the existing pass expires, we need to be able to offer our customers a new contract.

It also needs to be able to generate some reports, at the beginning it may just be a number of passes sold.

Well, when you hear all this, you might feel overwhelmed by the amount of different information out there. But I have to tell you that you are very lucky - I have personally had experiences where the development team was told just do the same as application X and that was the entire description of what we had to build. It is called pathology.

OK. Why am I so happy when I get a lot of information that scratches the surface but not the details? Well, the time for details will come in the workshops that you will organise later.

Now let's look at what information you have received and how you can extract what you need for the first workshops:

We want to build a SaaS application that can be used by any fitness studio. It will cover everything you can think of, from the initial offer to diet planning.

The first important thing you can take away from this conversation is that you need to build a SaaS application for fitness studios. This is a technical thing, but it also shows a business model (how you want to make money from it). Write it down, you will need to discuss this with your company after the business analysis workshops. Why? Quite often the idea that comes up may not be the best solution for the business and you are there to start discussions if you think there are better ways of doing things.

Let's look at the next part of the conversation:

We want to prepare offers and promote them to our potential and existing customers. If someone is interested in joining or renewing their membership, the contract should be signed.

Great, we have first requirements which we will look at in more detail during our workshops. Someone will prepare offers and advertise it to new and existing customers. If a person decides to accept it, contract will be signed. This provides you with a framework, so you can plan your workshops and define the objective on which you will focus. As you can probably see, there are different questions that might come at that point:

• Will the offer be fully prepared in our application?
• How will it be promoted? Newsletter? Within the application?
• What if the person is interested but wants a discount?
• Is the contract signed within the application or directly at the fitness studio?

These are questions that should be answered in your sessions with domain experts and decision makers. But it's great that we already have them. Write them down so you don't forget to mention them later.

Looking further ahead, we can see some other important information:

Once the contract has been signed, the client will be issued with a pass allowing access to the studio.

If you look back, you can see that there were already 4 business processes and the next one has just appeared:

• Offers preparation
• Offers promotion
• Contract preparation
• Contract signing
• Pass registration

The final step - pass registration - is the result of signing the contract and triggers the receipt of a pass by the customer. Again, the first questions that may come to mind are:

• How is the pass given to a customer?
• Is there only one way to do this or many, e.g. on-site, by email or by post?

and so on. Again, these are valuable concerns that should be noted and used in future discussions.

We have analysed almost the whole statement. There are 2 parts missing. First, let's close the area of customer management:

Of course, when the existing pass expires, we need to be able to offer our customers a new contract.

Here's how it works! When an existing pass expires, we send a new contract offer to the customer. The following questions may be asked:

• What does it mean when the pass expires?
• Should we prepare an offer before the pass expires?
• Should the discount be included in the contract offer?
• Is there a case where the contract should be automatically renewed?

Look at how much information about core business processes we have managed to extract from such a short statement! And this is just the beginning, because these are just your thoughts. You can imagine what will happen in brainstorming sessions.

The last part of the statement is not directly related to customers, but it can help fitness studios compare sales from month to month and prepare some goals to achieve in the coming months or year:

It also needs to be able to generate some reports, at the beginning it may just be a number of passes sold.

We want to be able to generate a report on the total number of passes sold. Ok, another area we need to focus on. At the moment we can assume that the decision on what kind of report to generate has been consulted with the fitness studios that will potentially use our application. If not, you have a perfect question to ask during workshops: Why was this specific report chosen for the MVP and not something else?

Congratulations! Now I advise you to structure the above information a bit and prepare yourself for workshops.

IMPORTANT: The above steps are not required, you can start directly in your workshops, but it always helped me to dig deeper into the topic before and just be well prepared. Often it is easy to forget to ask some questions and this way you increase the chance of remembering them.

Summary

So this is the time to focus on business analysis from a workshop perspective. In the next chapter you will learn about how to start your domain analysis with Event Storming and distill first subdomains based on its outcome.

Let's start with the draft of subdomains!

FREE Case Study: How did I introduce Domain-Driven Design in large scale organisation? Book an appointment with me to know more!