I am leading the Billing & Tax Teams At Bolt. Those are the part of the Commerce Department. If you think about Bolt as a whole, you discover that we have 4 business Verticals, Commerce underneath and Foundation for Bolt Engineering. It looks like the following:
The big goal for 2025 is going IPO. This requires intense effort from Commerce to prepare, as we need to be compliant across multiple dimensions. One of those dimensions is Billing.
At the same time, we need to bring efficiency to Billing, as it was built iteratively through the whole 10-year history of Bolt. It means that there is duplicating functionality in the Billing teams, and the solutions might not be as performant as it should be and not perfectly compliant. For example, we have refunds implemented in Billing Rides and in Billing Delivery; obviously this is not the most frugal approach.
However, in order to build a proper billing vision, which will be aligned with the big company goals(IPO), we need to understand how the verticals function now, what are differences between them and what are their similarities.
Imagine you're joining company to lead a department and the only think you know about them is that the result of their work are invoices which end users receive. How do you come up with the strategy for them? One of the approaches is "Light on the Hill". Another one is Event Storming.
Event Storming
This is a technique which helps you to understand the business domain well. Event Storming in a nutshell is a kind of a workshop where you go through 4 stages:
1.Brainstorm the events. You ask the workgroup to generate all the events that happen during the target process. Each event is represented by an orange card and state some event in the past tense. Like "Item added to the basket".
2. Next you want to refine and deduplicate the events. People will generate similar events, so you want to find the best description of the event. Also, you want to group adjacent events close to each other.
3. Then you want to perform the track analysis. Each event is caused by an actor or some system. Like the order can be confirmed by a user pressing the button on the page; payment can be completed by Payment Processing Subsystem, etc.
4. And finally you want to group events around the aggregates which they work with. Those are your domain entities.
Event Storming is an effective technique to understand what are you working with.
Our experience at Billing
I scheduled 6 event storming sessions, one per billing vertical team order and 2 for refunds, as they represent a different complex process. At this point we completed 4 of those.
At the beginning the team was skeptical about spending several hours at a time to put some color stickers on a Miro board. However, today - after 4th session, we experienced a breakthrough all together.
Across the sessions we created those aggregates, the examples of which you can find illustrated above. One of the aggregates, that we identified were Money Flow records. Those depicts where the money should go: from whom, to whom, what amount, what currency. It appears, that those records are a common aggregate amont the verticals, but each vertical has it implemented in their own way.
What we plan to do now as part of the bigger vision, is to create a common component for storing money flow in a compliant and efficient way and migrate billing vertical to using this component, achiving our bigger company goals.
Of course, this is just tiny step of building our vision, but I hope it clear demonstrates how you can come up with bigger picture using event storming.
Big thanks to Nikita, Anatoly, Oleksandr, Dima, Pavel B, Pavel, Robert, Roman, Iyri, Andrey, Lidia, Vladimir, August, Roman, Egor, Roman, Evgeniy, Nadia, Daria and Dzmitry for supporting the blog. They receive early access to the articles, influence the content and participate in the closed group where we discuss the architecture problems. They also see my daily updates on all the things I am working on. Join them at Patreon or Boosty, if you liked the article!