Had fun in the last three days of educational workshop, playing with a different domain.

Instead of something we had a real expert in the room, we've chosen to run the workshop on something we had real customer experience: the Italian railways company.

I've chosen that, because everybody acknowledges that it's a complex domain. Yet we managed to model a lot of it. Or at least to have an emergent structure and vision of the next step.

It's been actually fun, because we ended up with quite a few proposal for improvement that turned out easy on top of an Event-Driven architecture.

Food for thoughts.


Hey everybody,

I'm going to try out event storming within my company next week.
I really think my goal is to come to a common understanding and share the knowledge that is floating around in all the single heads.

In +Alberto Brandolini's book he states that this should not be used as a selling point for the strategy. So I wonder is it also a bad idea to set this as a goal for such a meeting?

Best Christian

Had an interesting conversation yesterday with +Paul Rayner about ...well almost everything! :-) However, one of the interesting bits was about strategies to wrap up the design artifact.

Looks like there are so many different ways to deal with that, and I am nowhere close to a definitive answer. So I'd like to hear your opinions/ideas about that.

Different context yesterday: more a product exploration than a business driven one.

The interesting bits were related to the fact that we were discovering designing not the perfect match for one specific organisation, but a more generic market fit.

Probably the most interesting one is that being right doesn't necessarily pay off: if the underlying problem is complex, but your users haven't realised it yet, they might be more inclined to buy something apparently simpler, matching their own mental model rather than something complex, that looks like "too much stuff I'll neve need". The real challenge became wrapping complexity with simplicity or presenting something with sophisticated internal machinery like a relatively trivial tool from the outside.

Other key point was: we have no guarantee that the customer's bottleneck is within scope. Our product might serve a support flow, and not the most critical one, or it might map with multiple bottlenecks in the company.

One of the approaches that seemed interesting was to try to solve at least one problem for a given category of users in a distinctive way, in order to hit the potential decision maker. Or consciously decide to focus primarily on some users, and limit ourselves to the basic homework in ancillary portions of the flow.


Post has attachment

How would you guys handle the following ?

The company I work for has a client here there are some issues.
The usual suspects, as far as I understand, lots of system, integration difficulties no real boundaries/ models defined.

There is this proposal to build an integration layer.. and that boils down to one drawing and a one liner.

I've been asked to make this more concrete during a traditional meeting next week, the CIO, some of the key project manager s & technical people will be present.

I planning to make them see that that even though this one liner & drawing is correct; they need to go more concrete. And that each case needs to be looked at one at a time and that the realization will need to take into account the actual need of the specific integration

I do sense the need for a Big Picture Event Storming.
But I'm not really sure how to suggest the idea.

Anybody had some similar experience to share ?

Some days ago I've tried EventStorming in an unusual context.

Most of the attendance was business, including some C level in a complex business. There's been some fuss around the meeting so a few more people joined and we ended up having 25 people in the rom focusing mostly on the sales process.

The operations itself was big enough to call for another 2 meetings entirely.

I wasn't given the room I wanted, and the lack of space kicked back in, since people had a hard time sorting all of the events, due to the lack of free space to shuffle things around.

In order to get out of the rabbit hole of sorting the whole story, we ended up using a smaller space as an area to sort "chapters" instead and sort a smaller version of the overall picture. Chapters were more or less the subdomains in DDD lingo.

This solved the impasse, because we now had an idea of the expected shape of the overall flow, but also created a lot of weird commentaries like "oh this should belong there" "No this should belong there!" ...as if categorisation and boxing was the real problem.

However, this was also the first time I'd have traded Events for something more coarse grained, since space limitation made managing all the huge event quantity hard to manage, and ended up postponing some interesting conversations.

- Room requirement are strict: half of the dysfunctional behaviour were in fact dependent on room size and to the Big Table in the center antipattern. Afternoon was kinda dysfunctional.
- Space matters: without slack space, shuffling things around becomes a lot harder.
- When business becomes really complex, a zoomed version of the overall flow could help envision the global shape.


This week I ran two 'light' eventstorming sessions for two different teams. We only had an hour, and limited wall space, so we only looked at high-level domain events and a context map.
Team member comments included:
- "this is the best onboarding experience I've ever had" (by a new team member)
- "I had no idea there were so many other external systems touching ours"

The cross-team discussions about how parts of the system really worked, etc were enlightening: though these teams have been working together for months, they had never explored their domain as a group.

+Alberto Brandolini: (1) thank you for this marveous, insightful technique, and (2) please finish your book - my book (Head First Domain-Driven Design) will reference yours, and it will be done in 2017. Tick tock! :)

Hello, I've started to study DDD recently. Then, reading the +Nick Chamberlain 's blog, I've started with Event Storming.

Spanish is my first language.

I'm helping to a couple of friends to model his system (a sports portal about local soccer news and results (matches, stats, etc)). The domain experts only speak spanish and I'm in the dilemma of choosing which language to use for the UL.

Coding using english but showing diagrams (ie event storming, context maps) in spanish start to look complicated. Coding using spanish mixed with English is a pain for the eye.

I'd love to hear your experiences/suggestions about this topic.

Post has attachment
Hello, colleagues!

I've posted my question here (http://ziobrando.blogspot.ru/2013/11/introducing-event-storming.html ), but it is also relevant in this Google+ Community.

To refresh: an event is a statement that something has happened, right? Also, events can be caused by commands. (Or, maybe, they are caused by commands only. E.g. occurrence of some moment in time can trigger commands like "Generate reports"). More precisely, event is not about something that "just happens", but about changed state of the domain.

But in context of CQRS we also have another dimension: queries and [what?]. How does EventStorming handle these concepts? And what is paired to queries: reports, facts, documents, info?.. Facts that we query for do not signal about domain changes - they just give us a slice of the domain's info. Fact is not only needed to make a decision and produce some command. It can be just consumed by user. As music, video or blog post.

So my question is: what concept matches queries and how should we discover/handle them both within EventStorming process?

Wait while more posts are being loaded