Understanding Eventsourcing - Book Review
Thanks to Bastian Waidelich I noticed that there’s a pretty fresh and new book on Event-Sourcing and Event Modeling written by Martin Dilger:
The book is available on Leanpub and also as printed edition from Amazon.
About the content
After having built a first application following the Event-Sourcing approach already (see https://spenden.srk-luzern.ch/ to see it live), that part of the book was not bringing me too much to learn. It was more of a repetition and good to follow and read up again to better memorize some details.
Much more interesting for me was the whole part about Event Modeling which is a structured way of capturing, clarifying, arranging, linking and documenting events that occur within a system. While I was aware of e.g. Event-Storming and think there was something like “Domain Mapping Workshops” (that I cannot find a reference right now), this Event Modeling approach is somehow new to me.
It reminds me a bit of something we do during incidents in the fire-department:
We visuzalize, with some simple rules, some signs, but besides that rather low-tech and flexible (adaptable to the current situation). And I really like this! Both such a sketched incident overview map and a Event-Model canvas look pretty wild and overwhelming to someone that has not seen that before and might now know “the rules”. But once you know the very simple rules, it all starts to make sense. The different colors become to have a meaning. That’s very cool! And still it’s simple and not overly complex to learn.
I’m eager to test it with others the next time we discuss about the flow of data and the events in a software-system, especially with non-techies, to see how good they understand it and whether the discussion benefits from this method.
My thoughts on the book
All in all the book was full of inspiration, with many images and examples illustrating the content. I really liked reading the whole book rather fast from start to end.
I really liked the combination of Event-Sourcing, documenting the flow of data - and also very rough sketches of the UI. Bringing that all together makes me think this will be beneficial in discussions, rather than having that spread in different locations.
The book could benefit from some proof-reading and polishing in general. In some sections the images are so small that the text on it is barely readable (and there’s no way to zoom in in the printed edition). Also a better typography would be cool (many cut-off parapgraphs with one line lonely on a separate page).
Besides that, the content in the book is great!
I just have to find out for myself if Miro is the way to go to document a system in the longer run. For sure, for the brainstorming/discussion time it’s fine. But what about later? May be the time after building the system initially?
And is the Miro board containing all relevant details? I think for the architectural level yes. But what about the implementation details? They are strictly kept out of the Event-Model and that makes sense. But somewhere I’m missing how to keep track of such “details” and how/why some decisions were made together with the documentation of the implementation. So far, the book seems to suggest “the Event Model is the whole documentation” and I think there’s something missing, especially I’m not yet convinced that a single Miro-Board alone will be sufficient.
Recommendation
I recommend the book to everyone that has something to do with architecting (software) systems the modern approach based on Events rather than storing just the current state.
My recommendation is to start drawing, discussing and refining the Event-Model like Martin Dilger wrote it in his book! Implementing that system in code afterwards will become pretty easy and definitely the shorter part of the work. (If it’s the “promised” 10% of time only is yet to be proven.)