Let’s get back to collaborating! One way to have conversations with stakeholders is to lock people in a room and not let them out until they agree. 😈 Or, you could try something fun, like event storming!
Event storming is a workshop where all interested stakeholders, including developers, map out the application. Just like use cases, you’re interested in finding the goals, but you're also looking at the connecting events that result in reaching the goal.
And of course, all the information from an event storming session is used to inform and improve your domain model. 🙂
Getting the Storming Session Ready
Before you actually get into the session, there are a few things you need to prepare ahead of time:
Define a reason to have the storming session.
For example, you’re building a new application or adding a new set of features to an existing one. You want the meeting to have a purpose, so it doesn’t wander all over the place. It will wander enough on its own, so have a loose set of boundaries.Invite the people.
Again, this will be your set of various stakeholders, plus developers.Set a time when everyone can make it.
That's the hard part. It’s like trying to get a group to agree on pizza toppings. There’s always someone who disagrees. So, do your best. If you can’t get everybody, most is a good compromise.Get your materials ready.
This is a brainstorming-type meeting, so you'll need plenty of space to move around. People will write ideas on sticky notes or note cards. You should have a big wall to put post-its on or several tables for the cards.
Got everything? Good. Let’s start an event storming meeting!
Run an Event Storming Meeting!
Now let's run through how to manage an event storming meeting. To help you get perspective on how to apply this methodology, we'll look at different examples in each section.
Step 1: Generate Ideas
Imagine that a group of roommates want to pool their money and buy a car to share. For that, they need to figure out how each of them would use the car, so they can (a) pick an appropriate one to buy, and (b) figure out a way to share it. Where to start? Have someone say a goal, and write it on a sticky. They might say:
A: "I'm going to use the car to drive to work."
Great. You can follow up with a question:
B: "How do you do that?"
A: "I start by unlocking the car."
B: "Terrific. I can imagine the system already. You enter a pin on the driver's side door..."
Whoa there. This is how you run into trouble. You're already considering the solution domain instead of focusing on the business domain. There's a big problem with that. You're hijacking the discussion, and it's supposed to be a brainstorming activity about using the car. They're now going to lose interest if you're focused on tech details.
Remember, the point is to foster conversation, and it can go anywhere. This may spark ideas about related features, or how this feature is part of a larger one. This is all good! Alright, write that down and continue.
Sometimes the discussion of one topic will lead to another. "Unlocking the car" might make you think of "starting the car," which in turn makes you think of "turning on my favorite music" and "heading out" or eventually "stuck in traffic." 🚦 That's OK! Remember, what you are ultimately trying to build. A domain model! So, the more information you have about the user perspective and vocabulary, the better.
Step 2: Group Ideas Together
At this point, you'll see a wall full of stickies. So, what do you do with that? You look for ideas that clump together. Go ahead and circle them. If you go back to the library example, you could start grouping actions people take around books:
You can even give that grouping a name like “book ordering” (which would include both first-time orders, and replacement of damaged books). You will use these groupings to help determine how you will build your domains.
Step 3: Dig Deeper and Find Event Triggers
One of the things you would like to understand is events and event triggers. Events are things that happen. Triggers are the cause of the event. Usually, user interaction with the system triggers an event. But it can also be another system interacting with yours. For example, your system might print out a shipping order in a factory warehouse. The trigger would come from a purchase order system either within, or outside, your organization.
To get to the root cause of this flow of activity, you can ask a question: What happened before this? Keep asking this question until there is no more "before." That will tell you how the user is going to interact with the system.
Here's an example from a restaurant application. It's being made so that waiters can track orders and payments. Let's listen in on the following discussion:
Developer: "What's the big goal we're trying to achieve?"
Waiter: "Getting paid for serving lunch."
Developer: "Why is that important?"
Waiter: "Well, it's how the restaurant stays in business."
Developer: "Ok, so what is expected to happen?"
Waiter: "The customer pays for their lunch with cash or card."
Developer: "What happened before that?"
Waiter: "The customer received their lunch."
Developer: "How did you know what to make?"
Waiter: "I took their order."
Developer: "How did they know what was available?"
Waiter: "They were given a menu."
Developer: "How did you know they needed a menu?"
Waiter: "They were seated at an empty table."
Developer: "How do you know which tables are empty?"
Waiter: "I look at the map of tables, and find one without people at it."
Developer: "How did people get added to tables?"
Waiter: "They are moved from the check-in list."
Developer: "How did they get on the check-in list?"
Waiter: "They walked in the door and said they were hungry."
So the triggering event is a customer entering the restaurant. The first interaction with the restaurant system is when they are added to the check-in list.
Once you've written these things down, this information will go into your domain model. Remember, the model doesn’t just exist as a formal document. It is carried through with your conversations, all the way to your code.
Try It Out for Yourself!
Organize an event storming session! Gather your materials, then invite a group of friends or roommates or family over. You can choose a general topic like "organizing a trip," "getting chores done," or "picking a Friday night movie" - anything that will get people talking. Capture all the information you can!
Once you've done it once with people you know well, you'll feel more confident doing the real thing with colleagues or clients!
Let's Recap!
Event storming is a workshop of stakeholders and developers to discuss how the system will work, from a user's perspective.
Have a purpose for the event storming session.
Pick the appropriate people, a good time, and a big-enough room.
Start with one idea, and let it evolve.
Keep going; don’t dive into implementation details.
All this new found knowledge is recaptured into your domain model.
Event storming helps you understand what the system does. Now you need to understand the stakeholders' definition of concepts. They will lead to a model.
In the next chapter, we'll look more in-depth at what goes into building a domain model.
