Extending the DDM modules in Liferay with custom field types isn’t that easy. This blog post is the result of our attempts...
Event Storming to observe software architectureStijn Vanpoucke
Event Storming in DDD
During DDD-Europe Alberto Brandolini gave a workshop about Event Storming. Currently he’s writing everything down in a book that is already partially available on leanpub.
Event Storming can be a very useful tool to model a Domain in a Domain Driven Design oriented project. It aids to discover Domain Events, Aggregates, Commands, Query Models, etc. This time we used it to observe the software landscape of our customer “Zorgbedrijf Roeselare“. Even without knowing much details beforehand, the result of the Event Storming assisted us in talking about their future strategy.
How an Event Storming session works
With a group of six people (from “Zorgbedrijf Roeselare” and ACA IT-Solutions) we started hanging up the IKEA paper roll in a room, this would become our timeline. We started by creating the first series of events with the entire group. We explained that an event should be described in the past tense and that each event should be written on a post-it. The group immediately came up with the idea to split the events over three important pillars. These are the subdomains, as we would call them in DDD terminology.
The group quickly understood that they should not go into every tiny detail with the short time period we had. After some time multiple flows of events started appearing on the walls. We used red post-its for things that weren’t clear, or to refer to a set of missing details. Because the primary goal of this workshop was to investigate the streams of data, we started adding the query models with purple post-its. An example of a query model could be a list of volunteers, a list of children, … And after working on this for half a day, we already had a clear view on what the company was doing and the needed data.
How Event Storming helps us improve software architecture
In the afternoon we used a whiteboard to draw the current architecture. We drew the connections between the applications and we wrote down the data that they contain. Now we were able to connect the result from the Event Storming exercise with the current software architecture. It allowed us to understand what the applications where doing, why information has to go from A to B, etc.
With all this knowledge in our hands, we were able to join the discussion about improvements in the software architecture as outsiders. We were able to use our experience from other projects and think about better integrations, knowing what the applications are functionally meant for.
I would definitely recommend taking a look at Event Storming. As explained in Brandolini’s book, there’s no need to follow everything step by step. You can use parts of it for whatever your goal is. You’ll always get more out of interactive exercises like this one than when you’re just sitting around a table.