Years ago I wanted to start learning Domain-Driven Design. It was quite a popular topic, many of my colleagues were discussing it. The problem, as always, was where to start.

I decided to ask one of my old mentors. He told me, "MJ, there is a great book about DDD called the Blue Book. Go and read it and everything will be clear. There is nothing better on the market". "Well, it must be super easy, I can read it in the next 2 months and I will be a master in this subject". - I thought.

I bought it. 8 years on from that moment I can tell you that it is indeed a priceless book. But (there is always a but) it took me 8! years of combining practice, knowledge from this book and others to get where I am now. Lots of bad decisions in projects and products I have been involved with, screwed up concepts, over-engineered architecture - this is what I have done.

It was a fantastic time, but I had to learn everything from my own mistakes (and those of my team).

That is why you are here. I want to help you, show you the way and convince you not to repeat my mistakes. Not to try to apply every single thing from books, tutorials and other materials. In fact, strategic Domain-Driven Design is not that complicated - it is not quantum physics, where our minds have to step out of the framework imposed on them from childhood. But (again!) it does require you to step out of your comfort zone and stop thinking in terms of technicalities - providers, controllers, managers and handlers. The most important thing is business.

And that is where this story begins.

Much of the material you can find on the internet and often in various books is quite scattered. It is not easy to find the knowledge in the form of a recipe - when, what and how to apply the knowledge in a practical way.

Let me warn you straight away - when it comes to building IT systems, there is no such thing as a silver bullet, a solution that will always work, no matter what environment we are in or what the state of the system is. However, I will try to give you a step-by-step guide that shows you the possibilities, and it works for me in the majority of projects I am involved in. In the end you will have to decide which of these steps you want to repeat, extend and which you want to skip.

All I give you is my knowledge and experience.

Understand your domain first

Each company has its own business domain (sometimes there are several, sometimes dozens, sometimes hundreds) in which it operates and earns money.

Joining a new company or project is often a very stressful time - either you have to prove that you are the right person for the job, or you have a lot of decisions to make. It is not uncommon for you to feel like you are on a rollercoaster full of architecture diagrams, books or sheets of requirements, new teammates, organisational things, and so on. Even if you are very 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 go deep into the business domain in which you operate. There is also a chance that you will be told that all the requirements are there, they are clear and we do not have time to focus on some business analysis.

That's where most problems and legacy systems start.

It is extremely important that you communicate clearly and loudly that there is a need to go through the domain and its processes again - you were not there and you will not understand many of them just by reading tons of documents. You will need to organise some workshops - usually you will need at least a few days to understand simple businesses and up to several weeks to analyse larger ones.

Often it is very difficult to convince people to do this when trust has not been established. So you usually only get one chance. And this one chance has to be made a success - if your workshop is full of quality, people are involved and (ideally) you find some misunderstandings, then the stage is set for future workshops.

The Project Paradox

If you do not understand the domain well, you are likely to fail in the long run. At the beginning of any project - when our knowledge is very limited - we have to make a lot of different decisions. Then, over time, our knowledge grows and the number of decisions decreases:

Due to the lack of knowledge and the fact that we are exposed to many decisions, we can expect that many of them will be wrong.

The question is why not spend more time at the beginning to understand what and why we want to build something, and improve the quality of our initial decisions? In the end, we will create safer environment around us and quite possibly avoid many of the problems that would have arisen had we skipped the initial steps.

Organise workshops

Well, the time has come - you have to organise your first workshop. The most important thing is to set yourself a goal, a result that you can work on and build on.

Personally, in most cases I want to discover and describe the most critical business case (process). The one for which the system will be built - fully or partially, sometimes parts of the business processes happen outside the system - example can be a process where in one step the request is sent to the national legal system and we have to wait a couple of weeks for the answer before we can continue the process in our company.

For this opener (the first workshop) you will ideally have decision makers - people who have the power to make such decisions - and domain experts - people who have a lot of knowledge about different parts of the process, e.g. logisticians, accountants, sales, lawyers etc. (if there is an existing legacy system, these may be the software developers who have worked with the system the most, as they usually have a lot of knowledge about the business).

When everything is defined:

• participants - I prefer not to have more than 8 because I cannot give my full attention to each person.
• place - on-site or remote - I prefer the on-site option as I have more interaction with the participants and people tend to be more active (based on my experience)
• time - how much time do we need for the workshop? For the first one I usually plan 3 times 1.5 hours * 2 days. If I see that we need more time (which happens quite often), then I plan for follow-ups

You can start thinking about the method, the technique you want to use. There are many different ways of doing it:

• Event Storming
• Domain Storytelling
• User Story Mapping
• Story Storming

and many other alternatives or combinations of the above. I usually opt for one of the first two - Event Storming and Domain Storytelling - and use them interchangeably depending on which is preferred.

How do I know what is preferred? I just choose it based on the initial information about the business process or ask before the workshop (e.g. with the survey) what would make people feel more comfortable:

if the process is new, or I get the answer that the majority of participants would prefer a sticky notes workshop, then I choose Brainstorming with Event Storming, where everyone is involved

If the process already exists or I get the answer that the majority of participants would prefer a workshop with diagrams, then I prefer Domain Storytelling

In many cases it is simply a matter of preference.

Summary

This chapter introduced you to the world of strategic Domain-Driven Design. You might have already seen that there was nothing yet about subdomains, their types, bounded contexts, domain and architecture patterns or context maps.

If you are surprised, great - that's exactly what I wanted to hear. Before we jump into the deep end, we have to go through the process of business analysis of a particular domain. Otherwise, we are just relying on theory, and that's something I really want to avoid.

In the next chapter we will work on a business domain called Fitness Studio. There we will discover together some business processes using one of them - Event Storming. Then, when our processes will be on the board, we will try to distill some subdomains (finally something directly related to Domain-Driven Design) based on concrete heuristics.

Buckle up and let us get to work on the domain!

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