Domain-Driven Design
Most developers already had the chance to hear or read about Domain-Driven Design. Long story short, this approach is meant to help in modeling complex domains by offering precise tools and encouraging the use of specific, domain-oriented ways of thinking. It is a powerful methodology that works perfectly well with greenfield projects. But what about a legacy system that was, in addition, poorly designed and maintained? The cost of introducing this approach to the entire company is huge, takes a lot of time, and requires some training courses (not only for developers). Thankfully, there is a simple technique invented by Alberto Brandolini called Event Storming. This is a good starting point for discovering Domain and introducing DDD.
Recently, we have started to implement the Domain-Driven approach together with one of our clients, and our goal is to integrate processes for discovering domains based on different Event Storming workshop variants. In the wake of a few sessions completed so far, we have reached some insights, and we would like to share some of them in this article.
Event Storming
First, let's focus on the workshop itself and its most popular variant, Big Picture Event Storming, with its basics and how to facilitate it. The main goal of this workshop is to gather all people that have a business, domain, or technical knowledge in one place and model the current understanding of the system.
You might say that there is nothing special about it, right? There are many other workshops and techniques that accomplish the same, so what makes Event Storming special?
The biggest advantage that speaks in favor of Event Storming is the clear, easy, and structured way of communication between employees from different company units. And because of that, we can naturally stimulate our participants to start a dialog, discussion, share thoughts and, most importantly, to agree on the language and discover it with us.
Event Storming step by step
To perform this workshop and make it successful, you need three key ingredients:
- The right people - a greater variety of the group, may color the final view by reducing bias, but be sure to invite only those people who have the most influence or knowledge about a given subject and care about the problem. They will be your domain experts. Developers with long service can be useful experts too, but they need to understand that the event should be considered as business-related.
- A good location - the room needs to have at least one long wall and be large enough to accommodate gathered people and give them some space.
- An experienced facilitator - you need a person or two who will ask the right questions, timebox every phase, and be able to explain all the rules and stages clearly so everyone would understand them.
Room
As I wrote before, the room needs to have a long, straight wall on which you will be able to stick paper rolls. The bigger the wall, the better. At least at the beginning, all the participants should have space to stand and walk, so you also need to move all the seats to the place or corner, which is not easily accessible. The next important thing is a table with a lot of sticky cards in different colors, a few markers and a board with a legend of what each card means.
Cards
Sticky cards are the best tool used in the meeting. In the Big Picture variant, we can differentiate between five types of cards.
Orange cards represent an event and are the main building blocks in our process. To be more precise, this is an event relevant from the domain expert perspective. Events should always be phrased at past tense. Example: Report was generated, Charging has stopped.
The yellow card represents people involved in some event or process. You can treat it as an actor as well. Remember that the goal is not to specify people for each event but to accentuate the involvement of someone outside of the system. Example: Portal user, Support team member
The violet card represents the system involved in some event or process. It can be either an external or internal system. The same as in the card for people, the clue here is to emphasize some external involvement. Example: Third party API, Database
The red card represents a hotspot. This is used for marking a place with the lack of proper knowledge, something that is not working well or to mark a place of disagreement between participants. This is a sign that we need to take a deeper look into it later. Example: Generating report takes to long
The green card represents an opportunity. It can be used for specifying something that is already working quite well, something that we can improve, or some other handy ideas. It can be a good alternative to the hotspot card for an attendee who prefers resolving problems rather than complaining. Example: Delivery reception can be automatized
Phases
Up to this point, we have a place to organize the workshop, we have the tools - but what is the process itself? To quickly answer this question, there are five different phases in this meeting:
- Chaotic exploration
- Enforcing the timeline
- People and Systems
- Backwards walkthrough
- Hotspots and Opportunities
Chaotic Exploration
To benefit from our long, carefully prepared paper board, we need to draw a small timeline at the top of it, explain what each card means, ask everyone to think about some events happening in the system, write down an event on the orange card, try to stick it somewhere on the timeline and do it again and again until everyone runs out of ideas. It’s easy as that! Nevertheless, we often run into a problem with starting to stick cards. In that case, you need to encourage everyone or place an example card yourself to show that it’s just placing a card on the board, nothing more. Since it’s chaotic exploration, the location on the timeline does not have to be 100% accurate but will be helpful during cleanup. This phase should not take long; if you see that no one is writing anything on the cards for more than a few minutes, you can just finish this phase. In the end, it should look more or less like on the image below.
Enforcing the timeline
After chaotic exploration, of course, we need to do some cleanup and sort out all the events we have gathered on the board. Unfortunately, it’s not as easy as it sounds. Some parallel processes will surely come up, people will try to kick all events around, and a lot of confusion will happen. To make this phase nice and effective, we can introduce some structure at the beginning. There are quite a few good strategies, but we highly recommend specifying a few pivotal events and introducing swimlanes. We ask our domain experts to choose up to four-five most significant events in the flow. They don’t have to be perfect; it’s enough if the other sequence of events is depending on some pivotal event and cannot happen without its occurrence. That will create a framework on the board, which makes sorting other events easier by determining whether they happen before or after a given pivotal event. We can introduce swimlanes for all sequences of events that can occur at the same time. When everything is put in order, it’s good to make a walkthrough from the first card to the last and assure everyone that they did a great job.
People and Systems
In this phase, we ask our domain experts to specify a few people and systems which play some role in the events. We need this information to have a full picture of the serious dependencies in the given system. It may also point to a place where there is no full control in the system, or where constraints and conditions are present.
Backwards walkthrough
So far, we have quite gained a lot of data about our domain, but still, it doesn’t feel as solid and detailed as it should be. To encourage our participants to be more creative and take a different perspective, we should spend more time on the backward walkthrough phase. In general, we need to ask someone from the audience to read out loud all the events starting from the last card. What is different now is that we ask additional questions like:
- What has happened before X?
- Is X a consequence of Y?
- Is there something more happening between X and Y?
- etc...
These questions will make domain experts think in different ways, stay focused, and not take something for granted. As a result, we will have new information and more details - and therefore, new events, new flows, and new structures. The most important rule here is to discuss and fill the magic gaps between events if they are apparent. There might be a situation when an agreement cannot be made due to a lack of knowledge. In that case, marking it as a hotspot is a good choice.
Hotspots and Opportunities
The last phase could be optional, but the overall picture of the system will gain a lot from that information. We would like our domain experts to specify hotspots - aspects to improve, and opportunities - ideas to introduce. After that, we organize short voting by drawing an arrow near the most important hotspot/opportunity in the system. This information is a very important sign that in any further discussion, we need to dig deeper into this area and try to solve this problem. We can also prepare a simple metric for a given hotspot/opportunity so it can be expressed with numbers, and as we know from our experience, numbers are intrinsic for business.
Helpful hints
As you have already seen, this workshop is not so complicated from a technical perspective and probably could be performed by anyone who knows its rules. However, just as in real life, details play the biggest role. Some obvious behaviours and attitudes are often forgotten in effect, so here are a few tips that came along with practice.
Stakeholder mapping
Event Storming is all about the people and their knowledge. The goal is to have as diverse and useful a group as possible. To achieve that, a simple stakeholder mapping technique comes in handy. We need to find a person who knows the system and the company quite well. It can be a Product Owner or someone from the management board. Then, together, try to determine potential participants on a simple figure with two axes: influence and interest. For simplicity's sake, we can divide the figure like in the image below and map people into those areas. The conclusions are self-imposed.
Clear goal
Remember to make the goal of the workshop clear to everyone, especially in the Big Picture variant. People often tend to lose their track if they don't narrow the scope a little by having an explicit reason for carrying out the workshop. That may result in many wrong, or irrelevant events, so unnecessary confusion could happen by accident in further phases.
Lead the meeting
A good facilitator is priceless and makes a huge difference during the workshop. Leading a workshop is a skill that demands time and experience to be improved, but fortunately, we have some advice on that matter (especially useful if you're just getting started).
At first, keep the meeting and rules in scheduled bounds and don't allow too much freestyle. Boundaries trigger creativity and require mental effort. The next thing is about too specific questions during the Big Picture Event Storming. Not everything is important and necessary at this level of abstraction. More details should be discovered later when the scope is limited, and we have a clear goal to deliberate specific aspects. When something is not clear, just mark it a hotspot.
The last and most important thing is to focus on the language that springs out during the discussion. Domain-Driven Design puts linguistic differences first, so try to pick up details and attributes up as much as you can. Ubiquitous language is necessary to appoint subdomains, and there is no time to write down everything that has been said.
Meaning of an event
If you gather people from different company units, they could have their own definition of an event. It is really important to have a common understanding that events should be relevant from a domain expert and from a business perspective. An event should not be connected to some implementation and technical concepts because it's highly probable that it doesn't reflect the problem and domain. Often, it is far and away from the business-related issue, especially when you are considering a legacy system that wasn't designed in a Domain Driven way.
Pivotal events
Do your best to specify good pivotal items. Ask as many detailed questions about chosen events as you can, e.g., "Are there some events that cannot happen if this event has not occurred?", "Is it necessary for some processes to start and go on?", etc.
This will speed up the cleanup phase, and in the future, it can point to a moment when the language is changing. Pivotal events often come with new processes that could be related to different subdomains.
Timeboxing
It's hard to book at least three hours in everyone's calendar. It's even harder to stay focused and feel good during such a long meeting. Proper timeboxing and breaks are a must. Spend your time, more or less, in these proportions:
- Chaotic exploration: about 10-20% of time
- 5-10 minutes of break
- Enforcing the timeline: about 30-40% of the time (cleanup takes some time)
- People and Systems: max 5-10% of time
- 5-10 minutes of break
- Backward walkthrough: 30-40% of the time (most of the details come up here)
- Hotspots and Opportunities: max 5-10% of time
Digitize the board
People would love to see the result of spending their precious time on discovering their domain. Also, from the perspective of a software architect, you need to have a better overall view and possibility to manage it without effort. Digitizing it seems to be the best solution, and for that, we recommend an online tool called Miro. It has a feature to capture sticky cards and convert them to online notes, which can save a lot of time.
What's next
Now that we have finished the workshop, everyone is completely exhausted but also satisfied with what they have achieved. And then they ask the important question: What is going to happen next?
The answer is simple. Now it's time for the domain architect to discover and validate the subdomains. We have a big picture view of the whole system, but we don't understand it yet, we cannot tell what exactly is happening underneath, what problems there are, and what exactly we want to solve.
We need to determine emerging subdomains. It's not easy; some even say it has more in common with art and intuition rather than logical patterns and equations. What's more, there are dozens of heuristics and techniques for doing it, and none of them are universal.
Nevertheless, here are a few worth mentioning.
Company structure
This can be a good entry point for further considerations. Each organization has different units that can reflect different subdomains. Unfortunately, business processes, which are a part of the core domain, often cross different departments, so we cannot rely on this heuristic much.
Domain expert division
It's a common situation that within one company unit, there are few domain experts responsible for different issues. This is a clear sign that we may expect different problems in one place and may need different subdomains.
Domain expert language
Probably the most important and practical heuristic, which assumes that words and terms have a different meaning in different contexts and subdomains. Company products have different meanings in the sales department and different meanings in the warehouse department. If we don't focus on the language, we risk failing to see these various perspectives, life cycles, and issues separation.
Business value
If some aspect comes with huge business value, it should probably be a separate subdomain. You can be almost pretty sure that this aspect is connected with the core domain, the company determinant.
Business process steps
Many business processes often involve different subdomains. Establishing factors that highly influence the process may point to a change of involved subdomain. Finding that might require introducing a clear chronology and asking for more details about what is happening between two events.
Final thoughts
When we specify subdomains that came down the pike at this stage, we should definitely present it to everyone concerned and confront our conclusions. For sure, it will be different in a few parts than the current system state, and that is completely normal. Maybe our thinking was wrong, maybe we didn't have enough information, or maybe the system implementation is not correct and should be refactored.
Nonetheless, one thing is sure: this is just a beginning. Now we need to go deeply into the details, organize another meeting where the scope of the goal would be narrowed to a specific subdomain. Here we can use a different Event Storming variant, concentrate more on technical details so that, in turn, a working architectural solution would be proposed. The true beauty of this technique is the constant divide and conquer, constant improvement.
But how to convince a decisive person that this effort and cost is worthy? Well, everything is about information and its meaning. Developers can't write good code if they have wrong information, wrong requirements, and don't understand the problem. This may result in large changes in code every time a new detail comes up together with more costs spent on maintenance. "Software development is a learning process; code is a side effect."
And finally, how to know when to stop learning and discovering the domain? To answer that, finding the design sweet spot is essential. It's a combination of development time, architecture planning, and time needed for rework. It's also highly dependent on the complexity of the system and available resources, but it will somehow visualize the most efficient compromise we can afford.
Conclusion
To conclude, at Solidstudio, we have carried a few workshops with our client and noticed clear benefits of them. We have confirmed which subdomains are well defined and properly embedded in the client’s system. But what is more important, we have noticed some opportunities for new subdomains which were not considered as separate logical units before. Observing language changes allowed us to define some valuable propositions for architectural design and to refactor the existing setup. Note that there are no silver bullets in architecture, and this technique may not bring the expected results on the first try. Despite that, it’s definitely worth a shot.