#13 Robust Architecture: Understand Your Domain First
Too often we start focusing on technical aspects of software architecture. Where to host it, how, deployment strategies and more. However, we forget about the crucial step of understanding the domain.
Each company operates in a specific business domain, such as healthcare, e-commerce, after-sales, or logistics. Sometimes, companies offer services in several domains.
Joining a new company or project is often a very stressful time. You have to prove that you are the right person for the job, and there are many decisions to make. It is not uncommon to feel like you are on a rollercoaster full of architecture diagrams, tons of requirements, new teammates, and organizational things.
Even if you are quite experienced, you may struggle with all the information coming your way.
Because of the above, there is a chance that you will not have time to explore your business domain in depth. You may also be told that all the requirements are clear and that we do not have time to focus on some business analysis.
That's where most problems and legacy systems start.
You must communicate clearly that you need to go through the domain and its processes again—you were not there when it was analyzed, and you cannot understand how it works just by reading a crazy amount of documents.
If you do not understand the domain well, you will likely fail in the long run.
The Project Paradox
When one's knowledge is limited at the beginning of a project (or product development), one has to make many decisions.
Then, over time, the amount of knowledge increases, but the number of decisions decreases. That’s the paradox:
Due to the lack of knowledge and the fact that you are exposed to many decisions, you can expect many of them to be wrong.
Why not spend more time understanding what and why you want to build and improve the quality of your initial decisions? In the end, you will create a safer environment and possibly avoid many of the problems that would have arisen had you skipped the initial steps.
One good idea is to organize workshops to gather this knowledge.
Organize first workshop(s)
In most cases, first, I want to discover and describe the most critical business process around which the system will be built.
It would be great to have decision-makers and domain experts in the workshop. Domain experts are the people who know the processes in the current domain and work with them. It can be logisticians, accountants, salespeople, or lawyers. If there is an existing legacy system, these may also be the software developers who work with it daily.
When the invitations are sent, you can start thinking about the technique you will use. Nowadays, one of the most popular are Event Storming and Domain Storytelling. You can use them separately or combine them.
One of my favorite methods is to combine them and use coarse-grained (high-level, abstract) Domain Storytelling first. I try to collect the story of the business process that we are going to model in the main workshop, for example, bike rental (simplified):
The customer wants to rent a bike. He starts the rental process by selecting the bike type and model. When the model is selected, he has to confirm the choice and pay for the bike. In case of successful payment, the invoice is sent to his email and the bike is rented. In case of failure, the process of payment repeats.
As an outcome, I have an easy-to-read diagram that shows +/- the entire process. Next, when the Event Storming workshop starts, I share the diagram with all participants before we start modeling. It usually takes 10-15 minutes to read and understand it. When participants are ready, we start the Big Picture Level workshop, where everyone focuses on events (business facts).
After the Big Picture, I plan follow-up sessions on the Process Level, where we all dive deeper into the selected business process and focus on actors, policies, commands, and read models.
Then, I repeat the above for all processes.
This helps me and everyone involved in project (or product) development to deeply understand the domain which is the key aspect of creating software architecture.
If you want to see how such a process works in practice, you can find a description in my free (no email required) booklet, “Mastering Strategic Domain-Driven Design.”
How do you discover and explore domains?