As part of FireHire, I’ve been working on implementation of an interesting and effective technique which sharing with you is crucial. Practical and functional things deserve sharing with others. As we’ve applied this group modeling technique, I find it to be the best time-efficient practice for most complex systems. Yes, I talk about Event storming.
Moreover, this practice is not limited solely to software engineering companies like ours. This process can be used for any project or technical domain which can be defined as tremendous and complex at the same time.
It is an interesting modeling technique which is easily done in a short period of time. At the same time it is useful for accelerating the developers’ team. If I compare the traditional modeling approaches that I’ve used throughout my working experience, it is easy to see that they usually do not deliver a comprehensive understanding of the domain in which the software should work. The better software engineers understand and grasp the domain, the better the implementation will be. And that is the primary goal of Domain-Driven Design.
The history of Event storming
This practice has a seemingly short history. The story starts with its very own creator Alberto Brandolini – the event stormer around the world. Starting from the point “I do not have time to draw precise UML diagrams” he dedicated time to experiment with new approaches. Later, he presented this technique to several conferences where the audience showed a positive feedback.
In 2013 this format gained great attention when people accepted and experimented on their own as well. They all confirmed its positive output and continually improved the model. At the end, it was clear that this is not just another format of modeling workshop.
What are the advantages of Event storming?
I dedicated quite some time to learn, understand and experiment with this format. To get a better picture of the Event storming, I’ve organized several internal Event storming sessions in my company. We’ve gained many advantages of implementing this format as part of our working culture.
No more shifting roles and responsibilities
Before implementing Event storming I had to transfer from one role to another in order to achieve a comprehensive understanding of the domain for which the software solution should be built. We had to be software architects, domain experts, test users and so many other profiles to accomplish the goal.
By adopting this modeling technique, we are just software engineers who perfectly understand the business model and ready to get the work done.
One team, one language, “one love”
The conventional techniques I’ve used previously included a small engineering team to participate in the client meetings. This approach more often than not, leads to lots of misunderstanding on the long run. The team ends up being focused on the implementation rather that the business domain.
With the Event storming approach, we now better understand the business needs. Thus, we are focusing on the creation of a single, unique and ubiquitous language for the specific domain before we start the implementation.
Enhanced communication and collaboration
One of the greatest values we gain from the Event storming is definitely the improved communication. Not every team member is DDD expert and this model technique makes the project scope understandable and clear for everyone.
The whole team can smoothly adapt to a single terminology of the business domain. Event storming makes easier for new members to join the project by aligning the business logic with coding principles thanks to the universal project language.
The importance of those sticky notes
The sessions’ dynamic and duration are the best way to have a perfect overview of what would be the domain of the software engineering we should provide by our side.
Every business process written on the sticky notes will remain in the room. But more important is what me and my team have learned from the domain experts that will persist while planning, coding and implementing the software solution.
I can assure you that it is easier and quicker to make changes on the sticky notes than to the production code.
But that’s not all …
Having a lot of event-storming sessions so far, I’ve noticed many other benefits that flow around the ones described above.
As the discussion during the session takes place, it is notable how the experts allocate. Specific experts show more knowledge about a particular field and the other for another field. The session heads in the direction of discovering new sub domains and domain bounded contexts.
My final words
Having in mind all the advantages of using this modellng technique for a longer period of time, the very best thing about the Event storming is that when the modeling process finishes, the domain implementation will reflect in the code. In addition, I can validate my code at the very beginning.
As part of software engineering team you should consider this combination of discussion and Domain-Driven implementation for boosting massive improvements.
In the next blog post I’ll provide our advice and insights for the Event storming agenda. You can read about what do’s and dont’s should be practiced and how to have an overall great success even from the first Event storming.
Stay tuned!