The very first #DDDBE event: the modellathon
Some background info
For the people who do not know the concept of a modellathon - in fact, I think we might even have invented the term maybe, but I am not quite sure -, it was something we spiked like a while a go, while coming back from the London DDD Exchange: As we were sitting together on the train with some of the #CQRSBeers guys, we considered starting a Belgian DDD community, and having real workshops.
Somehow the idea for the first workshop emerged: instead of having hackathons (hacking away on code), why not have a modellathon (hacking away on domain models).
Apparently the modellathon term was Jef Claes' idea !
@ToJans For the record, I coined the term on our way back from DDDX ;)— Jef Claes (@JefClaes) September 4, 2013
So one thing came to another, and all of a sudden we were in this situation:
This was not your average fictuous model, we even received some official Kazachstan documents:
We were divided into groups of 4 people, trying to make sure that at least one person having experience in domain modelling was in every group.
Just to elaborate on the “experienced” part: when we asked who had experience in domain modelling, not a lot of fingers went up, but when we asked who had managed to build a domain model in the past, that somehow turned out to be completely wrong, some more fingers went up.
The role of the expert was just to find a way to get started, but once you have the juices flowing, the expert’s opinion is as valuable as anyone else’s. So it is more about facilitating the process then being good in the whole modelling part.
On to the modelling part
During the first pomodoro of the modellathon (after a general introduction by the domain experts), people started experimenting with different kinds of modelling at different groups.
A lot of people were trying to use the event storming approach - as they had experienced the value of the technique in a really great workshop with Alberto Brandolini during Vaughn Vernon’s IDDD tour in Belgium.
Somehow this approach did not feel valuable to us in this phase of the domain analysis, as the question was more about the report we initially got:
- Why was having only this piece of paper not a viable solution?
- Why does the business need the system? What does it need to do?
So we started asking questions from there, and all of a sudden the domain experts were mentioning concepts like observations and evaluations. So instead of focussing on the part where you process grades/tests/students/whatever, the domain experts were focussed on that part; the report was only a deliverable from the system, not the system in itself.
From this knowledge we could build a conceptual model of teachers being able to track the observations, progress and expectations in a graph-like model with time on one axis and skill on the other, just finding a way to represent the domain to the experts on paper…
The @DDDBE guys decided to put a picture of us explaining our model on twitter, and I would like to sincerely thank them for for photographing me from my best side ;-).
After another pomodoro, we evolved into this high overview model where we found out that observations (like grades, tests, but also subjective observations) were not always side-effect free, and there had to be some kind of a formal evaluation process for an observation; this finally resulted in the flow of observation (1..n) -> evaluation (1..n) -> progress x learning goals (1..n) -> expectations and back….
Then all of a sudden the DDD cowboy - AKA Yves Reynhout came along, and he stated the model might be to abstract to be usable, and challenged us to mock up a UI to prove it.
So we did, and by building this mockup for the evaluation part, we managed to get an even deeper understanding of the domain…
We noticed the higher level overview might have been all that was required for this particular bounded context or subdomain, because it made sense by mocking up the UI.
The most interesting part however, is how we progressed from mapping nouns from the specs to trying to find out why the system was needed (Root cause analysis/5 why’s - anyone?). Then, by modelling our UI mockup, we were able to verify whether our assumed domain model would be usable in the real world…
Well, this was a really interesting exercise to perform; I think the biggest lesson in all this, was to experiment, and not being afraid of starting over, especially using a different modelling approach. As we all observed in the end, and Mathias mentioned in the beginning:
“essentially, all models are wrong, but some are useful” - George Edward Pelham Box
Hence, we could coin the concept model storming (initally mentioned by Mr. Brandolini I assume - give credit when it’s due -) as the best approach to doing things: find several ways to model your domain, and gain new insights every time you do it.
A note about the #DDDBE community
Well, there is not a lot to say about that from my side, except that you were all pretty awesome; this was a huge experiment, but somehow we managed to get an interactive workshop where A LOT of people contributed.
Based on the feedback you provided, I am quite confident we can do a lot more with this community, so once again, everyone, feel free to suggest and improve, or even join!!
We also had - once again - some interesting discussions afterwards, and I even managed to see a fellow DDD practitioner (which shall remain unnamed) perform a musical masterpiece on the day after!
Marco "owning the didg" at my place ;) pic.twitter.com/xHFQFNfKde— Tom Janssens (@ToJans) September 4, 2013
I hope we see you at the next event!
- Belgian Domain-Driven Design community domaindriven.be
- @DDDBE on Twitter
- Writeup by Mathias Verraes
- Photo’s by Stijn Volders
- Writeup by Jef Claes
!!! Breaking news !!!
This just came in; he who shall not be named A.K.A. the Mob/Godfather of Event- & Modelstorming approves!