Struggle Buddy Blog

June 26, 2021 - Event Storming!

Understanding the world in which we're playing, the causes and effects, the ins and outs, and the power of sticky notes.
By Ben Laughter

So, we had a startup idea. Several really, but this is the one that got us excited. We're putting something positive out there that we'll be proud of as dads, entrepreneurs, partners, and technologists. But an idea isn't a solution. A solution needs to be built. And to build a thing, one must understand that thing and the world in which it lives.

Any time you're creating a technical solution, you're eventually forced into logical statements. This happens, which causes that to happen, which results in that over there. It's typically very linear and logical. The best technology is great at making logic intuitive. It guides people to do the right thing next to extract maximum value. Think of the last time you called an Uber. How many steps was it? How many opportunities were there for you to deviate from the path that led to calling a car? Not many, right? They're absolute ninjas at understanding the relationships between cause, effect, and desire.

We want to be even better than that. So, before we begin writing code, we're wanting to fully understand the world in which the code lives! So Mike introduced me to two new concepts. Domain Driven Design and Event Storming. Let's break them down.

Domain Driven Design is a framework and methodology for creating software that goes beyond the typical tech questions like "What should I build? How should I build it? How should it work?". It asks deeper questions about why something is being built. What other systems are operating around it that influence users. Why does that particular effect follow that particular cause? It forces you to ask questions about what happens long before someone logs in for the first time. What's their life journey that led to that Google search on that particular day?

If DDD is the framework, Event Storming is the activity itself. Think of brainstorming on a whiteboard, segmented and color coded with sticky notes identifying actions taken (e.g. connection made, habit milestone reached), causes, agents (e.g. the user, the system), and more. Every component of what's going on is identified and compartmentalized so that you end up with discrete pockets of functionality that need to interact with one another.

Do the bus mechanic and the
bus driver use the same tools
and resources?

As an example, ask yourself... Does the activity of a bus mechanic need to directly interface with the driver? Should the driver sit in the bus while the mechanic works on the transmission? Do they use the same tools or resources? Probably not, right? The garage is one area of functionality and logistics. The route is another. So, the agents, events, and causes on the route are managed by a completely different set of rules and processes as the garage.

Event Storming helps you identify these compartments within your product. In our case, we realize that identifying a habit is a completely different set of factors than finding a buddy.