Event Storming — Build Real-World Event-Driven Microservices Part 4 — Analysis
One of the most important parts of designing a new system is analysis. There are many ways to analyze your future system. Every of them is less or more suitable for the type of the target system.
As I promised, these articles will be more practical and I will show you which technique I’ve used in my / our system.
Let’s jump to the Event Storming.
That is a great way to discover target systems or enterprise domains. Event storming is especially useful for designing event-driven systems. We will use it practically and directly for designing our system. But you can find so many very useful articles about theory out there.
The best way to use this technique is with a group of people from the technical and business world. You can combine physical and remote presence in these sessions.
We will not use a physical dashboard in our case, but we are going to use the Miro App.
Aim of the Event Storming session is to draw your system by color sticky notes. Every color has a special meaning.
Step 1
As the first step we will try to find all events in our real-world system. Try to imagine that you are part of this system like one of the employees. Every event or paperwork process has to be expressed as a sticky note on the dashboard.
It’s possible to start with a chaotic discovery of the system without chronological order. But I think that it’s more natural to find all events from the beginning to the end. Every event is represented by orange sticky note.
Our system is a CRM for tattoo studios. For more information let’s check my previous article.
We will create all events which are important for the system.
Clients
We will start with clients.
In our case there are these events: Client Created, Client Verified and more.
Designs
Another part of our business is design. The design is a contract between the tattoo artist and client. I suggest these events: Design Created, Design Descriptions Changed, Design accepted and more
Session Events
And the last part of our system is meeting with a customer which is covered by an event module. We have the following domain events: Event created, Event rescheduled and Event deleted.
Now we are done with the first step. We designed just basic events and feel free to add all required events for your system.
Step 2
Another step is sorting our events. In our case it’s not required because we did it during the first step.
Step 3
Next step is to add other parts of our system. We are going to add Commands, External systems, Actors and more.
Step 4
Now we are going to find our aggregates. Which are adepts for aggregate roots in domain driven design terminology.
Step 5
It’s time to define our boundaries. Which are candidates for our future microservices.
Next steps
You can add other elements.
For example, it’s very useful to use red sticky notes for questions without answers and possible issues. You can resolve it in a smaller audience like face to face meeting with a domain expert.
Conclusion
Don’t try to have this model perfect. It’s just a tool for better domain discovery and sometimes it can be used just for the creation of the big picture. Like in our case.
You can see this article as video on my youtube channel