Profile cover photo
Profile photo
Paul Rayner
Communities and Collections
View all

I facilitated an Event Storming exercise at a client last week over the course of two mornings as part of a project inception.

Each morning I facilitated the session as a series of three one-hour iterations, with 15-20 mins for event storming, 30 mins of group dialog/reflection, then a 10 min break. Then repeat. This is a common diverge/explore/converge approach I use for facilitating collaborative design sessions. I find the timeboxing, iterative review, and breakout groups to be a very effective combination.

Both mornings we had the whole group, about 15 people, including developers, testers, Scrum Master, and Product Owner. The second morning I broke them into 4 breakout groups, each tackling a different area of the problem, with the Product Owner moving around the room between groups. The whole-team dialog time then consisted of a 3 min presentation from each group, highlighting their key learnings and questions, with 5-10 mins of whole-team feedback for that group to feed into the next round of modeling. The last hour of each session was focused on the breakout groups consolidating the overall model.

The energy and fun level stayed high and there were many key insights generated. Also, a number of the team members were new to the domain and it helped them get up to speed very quickly with the project. They were all very happy with how the session went and how much they learned in such a short time.

It was a large problem space, so two 3-hour sessions was barely enough to capture the main ideas. With another two sessions, we would have been able to explore different models and dig deeper into the interaction between the 4 different bounded contexts we identified.

Related to this, one thing that concerned me is that frequently I see teams adopting the first model they come up with, which is always the weakest. After an initial modeling session the team may have an initial model and design expressed on the butcher's paper, but haven't really iterated on it much.

When I run domain modeling workshops, usually day one is exploring the team's current understanding of the domain. The second full day involves experimenting with alternative models, to see what concepts might be missing ("crash-testing the domain model") and looking for ways to improve the design. We may also walk through some code. Day three is about consolidating the thinking and distilling down the learning, domain model, and reference scenarios. We only did the equivalent of a single day, so I had to leave before we could dig deeper.

We questioned assumptions (asking "why?") quite a bit during the modeling, but didn't experiment much with modeling things completely differently. This troubled me a bit, as I noticed at least one critical concept that seemed implicit only in their model. I emailed the team leadership after the workshop to recommend the key domain concept to try modeling explicitly, but haven't heard yet whether they did or not.

I forced them to anchor the entire session around a concrete business example. I can't emphasize how valuable this was to the team's understanding, keeping the modeling on track, and generating insights into the nature of the domain.

One question that came out of the ES session last week. How do you guys model status changes in a workflow, such as an entity going from Pending, to Approved, to Active etc. These are not their statuses, but a common pattern I encounter.

I had them create events for an entity such as "Marked As Pending" and "Approved" and "Activated". For a CRUD-type system, devs don't think of these as events at all, but rather as continuous states of play that enable or disable other behavior.

I tried to steer them into thinking of something like Activated as an event, and then saying certain behavior was then permissible or not based on whether that event had yet occurred.

Any EventStormers conventions I should be aware of for this pattern?

Did some EventStorming last week at a client, with really great results. I also can't post pictures due to NDAs, but wanted to share some things I learned.

As Alberto and Mattias know, I've never seen anyone else do EventStorming, so I'm doing my best to adapt what I've read to my own facilitation style. It's probably more EventStorming Lite at this point, until I can see a whole day workshop or something.

This was with three developers, all of whom have attended an Immersion class, but two of whom are still relatively new to DDD as practictioners and one with a lot of experience.

We mapped out events for the main flow through their existing monolithic CRUD application. We laid out events as a first pass. Then I had them affinity group the events. It surprised me how clearly aggregate boundaries emerged as we did this. Not to them, but they became crystal clear to me as I observed them do it.

It also showed how they had over-constrained certain operations transactionally when part of the updates should actually be triggered by events that happen much later in the process.

Since all the system behavior is currently implicit, it made key business rules explicit as we talked about when events could actually happen.

We also did EventStorming to brainstorm how things might work for a couple of key scenarios, as I went about proposing a completely new model for them to work from to try to break up some of their current-model thinking. Also very interesting and enlightening.

Much more to say here, but I'll throw it open for any questions as I'm not sure what you might be interested in.

Post has attachment
I'm looking into using one or more of these babies to provide WiFi for Mile High DDD. Seems solid. Anyone ever used something similar for a conference?
Add a comment...

Post has attachment
Paul Rayner hung out with 1 person. <a class='ot-hashtag' href=''>#hangoutsonair</a>Daniel Hinojosa
Add a comment...
Wait while more posts are being loaded