With this blog post I would like to bring your attention to Event Storming and share our impressions about this approach after our first official try guided by Mariusz Gil – Event Storming precursor in Poland, great advocate and Co-Founder at Source Ministry.
Hello there! I’m Bartek, software engineer at Sylius and it’s a real pleasure for me to write this very first article for our community.
In Sylius we believe that the major part of software development process is all about learning more and more use cases, being focused on exploring project’s domain and creating common term dictionary with the client. For us, high quality code is an effect of a well-understood business process.
In one of the earlier blog posts, Mateusz stated that Behaviour-Driven-Development is one of the strongest fundamentals that Sylius is built on. Among a bunch of advantages that BDD brings into Sylius workflow, decreased number of translations between technical and business people seems to be one of the most crucial ones.
But what happens when after writing Behat tests and implementing given scenarios we realise that we have missed something? If the implementation of a forgotten use case affects code that has already been written, it could be frustrating and give an impression of domain misunderstanding. The essential question is – how to avoid that in possibly most effective way? Here comes Event Storming.
„Event Storming” expression often brings thoughts about Event Sourcing, but these two approaches touch completely different layers of software development process. While Event Sourcing is one of code implementation methods, Event Storming is all about getting into the domain defined by business people. It doesn’t provide you any answers about implementation process, what kind of technology you should use or how should you test your solution.
It all starts with a domain that will be stormed, a single sticky note and a group of a few technical and business people. The first step is writing the first event that comes to your mind that may occur in the domain and then pasting it on the wall. What happens next is the essence of storming – providing further events in an unorganized, chaotic way, without any order.
Pure magic happens within next few hours. It occurs that during a single session both technical and business specialists may realise that the whole team is left with a plenty of questions that still are yet to be answered. What’s more, thanks to both technical and business experts’ participation, all doubts can be understood in the same way by everyone.
After deciding where are the hotspots that require more knowledge to be gained, session participants try to organize previously placed events in order to distinguish a few key processes in the domain. Starting from this point, the domain can be described using several sentences, where each covers a plenty of events. Is’s a simple and straight way of creating user stories that will be used for first implementation step which is Behaviour-Driven-Development.
The Event Storming session itself is not so plain and simple as it may seem, though. Although at the very beginning it delivers much fun and satisfaction, after a while it occurs that without a facilitator encountered domain problems may turn out to be overwhelmingly complicated and difficult to solve. That’s the moment when Mariusz came in with his impressive process knowledge, ideas and advices on how to tackle issues like insufficient domain understanding or challenges during creation of common naming convention.
Let’s set an example of several Sylius upcoming features, which are returns and refunds. Even though it was our first time using Event Storming to explore the domain of these, we quickly realised that there are much more questions to ask than we previously expected and if it wasn’t for Event Storming, we probably wouldn’t ask them in an appropriate moment.
After a nearly seven-hour long Event Storming session including asking crucial, domain-related questions, several misunderstandings and „aha” moments, the whole Sylius team managed to create an event-based model of the upcoming feature. Despite being exhausted, we asked ourselves how was it possible that we have managed to develop our solutions for eCommerce problems without such knowledge and approach.
That also seemed to be Mariusz’s goal – to provide the process that will combat the most common domain-related problems that any team may encounter during software development. Now, when the technical and business people’s problem understanding is on the same level, it’s much easier to successfully use BDD approach, which is the beginning of every user story implementation in Sylius.
Hence, considering all factors mentioned above, an Event Storming session with a qualified focalizer such as Mariusz should definitely be an important point on your roadmap provided you are a BDD and DDD geek like the whole Sylius team. The stunning mixture of facilitator’s soft skills and high technical knowledge is definitely something that can make your first steps in Event Storming much easier.
We are extremely excited to push Behaviour-Driven-Development forward and rise Domain-Driven-Design to a higher level. You should definitely try it!
For more information and materials on Event Storming you can visit Mariusz’s GitHub repository.
