lastminute.com logo

Technology

Event Storming Experience

rabbani_kajamohideen
rabbani kajamohideen

The biggest challenge on adapting to Domain Driven Design is to change the mindset of people in their design thinking and bring everyone to the same page. Here we are sharing our own experience on how we tackled these challenges with the powerful Event Storming workshop


What is Event Storming ?

Event Storming is a workshop format for quickly exploring complex business domains. It’s intended to create and share a common understanding of a domain model which is called a “Big Picture” of your business. Traditionally, any workshop focuses on a specific problem with a small group, while for event storming you need to invite all the stakeholders who are key to your business domain. In short, invite all the people who want to ask questions and the people who know the answers.

Explore here for more information about Event Storming.

What is required to conduct Event Storming?

First you need to have the right set of people in the room with lot of sticky notes and large modeling space. I will not stress too much on the color of sticky notes, however it’s highly recommended to use different colors for different things.

Once we have the above items, then the facilitator job is to orchestrate the steps. It’s a step by step process and be aware to introduce them one by one with the proper legend because each step requires lot of collaboration and thinking and most importantly you should feel the flow of your business/domain picture.

Ready, Steady, GO!

We started the workshop with an objective to create the “Big Picture” for one of our business critical product where we believe the domain was complex.

As mentioned earlier, we brainstormed the following items in sequence.

Domain Event

Domain Event is the core part of your Event Storming model and everything will get evolved around this. Imagine Domain Event is something meaningful happened in your domain and its more relevant to your business. Avoid perfection at this stage in defining the Domain Event. Try to collect as much as possible from the audience and always we can refine it in the later steps.

Timeline is an important aspect when you are placing the Domain Events in your modeling space, it has to be in the sequence of occurring in your business model.

Command

A Command is one of the origin of your domain event. In other words, ask yourself what triggered this event (e.g., users, other events, or external systems).

Process

A Process is a reactive behavior on your domain event. Just apply the keyword “Whenever” to identify the applicable process on your domain event. In this step commands and events get connected properly.

Aggregate

An Aggregate is a group of commands and events in your domain model. In this step, we will bring all the relevant commands and events together to identify the aggregate.

Let me explain, all the above terms with a simple illustration. In the below picture, “Account Created” is one of the Domain Event and is originated by the Command called “Create Command”. Whenever Account Created there will be a Process which triggers another Command or External System to continue the funnel.

If we group all the Commands and Domain Events in this picture, then we are forming an Aggregate called “Account”. Its one of the critical building block of Domain Driven Design (DDD) and a group of aggregates will lead to identify the Bounded Context. So at last we designed our micro services based on Bounded Context 😍.

Aggregate
Aggregate

How it’s related to Domain Driven Design

DDD practitioner likes this approach since the output model from the event storming will be perfectly aligned with Domain Driven Design (DDD) implementation style. All the elements identified in the Event Storming such as Commands, Domain Events and Aggregates are directly transformed into your software artifacts. Eventually, the domain events are the one which will be stored in event logs or event store in a DDD based Command Query Responsibility Segregation (CQRS ) system.

We derived the following Context Map from this workshop and this becomes the base line for the entire product development.

Context Map
Context Map

Conclusion

Finally this is what we achieved at the end of the workshop after spending a fruitful 6 hours as a team and everyone felt it was a productive day. Most importantly this was referred as a baseline for our design model and henceforth referred in our design discussions to bring people to the same space.

Event Storming Final Result
Event Storming Final Result

From my point of view, it’s a very powerful workshop where you can gather lot of information about your business domain in single place. Also, you can directly derive your design model from this big picture in few hours. If you need to achieve a similar output in a traditional collaborative model then it takes couple of weeks, whereas with the help of Event Storming you can get the same result in a day or two.

I would suggest everyone to give a try, and have this fun filling learning experience.


Read next

SwiftUI and the Text concatenations super powers

SwiftUI and the Text concatenations super powers

fabrizio_duroni
fabrizio duroni
marco_de_lucchi
marco de lucchi

Do you need a way to compose beautiful text with images and custom font like you are used with Attributed String. The Text component has everything we need to create some sort of 'attributed text' directly in SwiftUI. Let's go!!! [...]

A Monorepo Experiment: reuniting a JVM-based codebase

A Monorepo Experiment: reuniting a JVM-based codebase

luigi_noto
luigi noto

Continuing the Monorepo exploration series, we’ll see in action a real-life example of a monorepo for JVM-based languages, implemented with Maven, that runs in continuous integration. The experiment of reuniting a codebase of ~700K lines of code from many projects and shared libraries, into a single repository. [...]