I think it was very good and worth traveling here from far. I would recommend however to have some theory section well demarcated to display some code examples as guidelines, they have to be simple enough to be interluded in less than 30 seconds but that can give insight to all groups per equal what would it look like to go down a certain path.
The invitation of the other 2 participants was a very good idea. Maybe an improvement would be to know when someone will or will not speak so that the flow is more continuous, though overall it was a very good insight from all fronts non stop which is superb.
Thanks! great workshop! I hope now I am a certified DDD-event-storming Engineer ^_^
Great workshop, glad I attended! Having Mr Brandolini there was a really nice addition, his insights about the whole process helped me a lot.
A few points (well actually it boils down to one major point) that would improve the training for me:
For me, near the end of the session it got the most interesting and felt we were cut short there. Had the feeling we followed the trail from scratch to code for about three fourths, which was a bit frustrating. Stijn explained me with a nice UML diagram what the flow would be of a command being processed in a CQRS system, these five minutes were worth a lot and boosted my understanding of how one would implement all that stuff. I would do more of that, in a structured way in front of everyone, instead of waiting for a student to ask about it and quickly explain it in person.
It's an event storming workshop so naturally there is a focus on the actual event storming, but the event storming itself isn't worth all that much if you don't know how to turn the mental model of commands, events and business rules into working code. That's why I would keep the event storming exercise a bit shorter (after two hours you get the point) and move on to the rest faster, allowing more time at the end to get into some implementation details. As always, a good example is worth a 1000 (I actually think a lot more than 1000) words.
You train people who code for a living. I am confident pretty much everyone in the room was left wondering how to take the car rental example further, into the realm of the pragmatic. So I think choosing just one of the cases that comes out of the modelling session and take an hour to turn it into pseudo code would boost the value of the workshop enormously.
It was a very good workshop (with actually a lot of work), but the fact that there were three of you had advantages and disadvantages. There were a lot of good additions and comments, but it made the day less structured.
Two things that could come in handy: a flipchart (or a piece of paper), listing the days topics (without actually writing down the technical names) so people now where you're heading (and when you've completed a topic). And a handout in the end with all the vocabulary so people say the correct names/verbs/etc... to other people).
The DDDBE modellathon was the first time I heard about event sourcing and I liked doing this exercise again. I was great to have 3 people around to ask questions. Thanks!
Very interesting topic, but in the end I found it a little bit hard to follow because of the lack of code examples. The presentation given the saturday after really cleared a lot up for me and it would have been a big help if that was integrated with the course or something.
Very asome tutorial on how to do event storming and to learn about event sourcing. It changed my perspective on data storage and blew my mind away how to loop at domains. I wil start experimenting on domain driven design and development.
I think to have some slides with code or make some implementation example would have helped. We spent a lot of time thinking about answers that were given but later on, but even if it was a guided exercise to come up with answers from us, then it feels like letting the time pass to fill the day rather than actually getting this rapidly so we can cover more material.
The workshop has a lot of merit but I personally think it is easy to turn this workshop into some `agile` conversation which was not very well envisioned by the title. Event brainstorming has part of this but I think perhaps just half of day should be practical the other should be more theory?
It was a fantastic workshop. Having three people to ask questions was a really good move.
My only suggestion for the speaker is to have a look at the timing. We got plenty of time for the first part (generating events) but the parts after that (identifying commands and business rules) felt a little rushed. That can be a bit problematic since creating aggregates relies on having a few good combinations of events/commands/rules on the board.
It was an interesting workshop to attend - it was interesting to experience a different way of modelling from the "classical" strategy of starting with entities and relations. I agree with the anonymous comment made at 2014-06-27 07:21, that a theoretical introduction would have been nice.
The last part of the workshop would have benefitted from a more code-oriented approach. A demonstration of how to turn this into an actual implementation (perhaps using Buttercup as an example) would have made me leave the conference with more confidence that I can actually use this in my daily coding practice.
Very interesting topic, this was the second time I did this workshop but it was changed a little and also very good to refresh my memory. I definitely try this technique (and CQRS). The only reason not to give 5 stars is to prevent Matthias and Stijn from getting lazy ;-) So keep on going!
Comments
Comments are closed.
I think it was very good and worth traveling here from far. I would recommend however to have some theory section well demarcated to display some code examples as guidelines, they have to be simple enough to be interluded in less than 30 seconds but that can give insight to all groups per equal what would it look like to go down a certain path.
The invitation of the other 2 participants was a very good idea. Maybe an improvement would be to know when someone will or will not speak so that the flow is more continuous, though overall it was a very good insight from all fronts non stop which is superb.
Thanks! great workshop! I hope now I am a certified DDD-event-storming Engineer ^_^
Great workshop, glad I attended! Having Mr Brandolini there was a really nice addition, his insights about the whole process helped me a lot.
A few points (well actually it boils down to one major point) that would improve the training for me:
For me, near the end of the session it got the most interesting and felt we were cut short there. Had the feeling we followed the trail from scratch to code for about three fourths, which was a bit frustrating. Stijn explained me with a nice UML diagram what the flow would be of a command being processed in a CQRS system, these five minutes were worth a lot and boosted my understanding of how one would implement all that stuff. I would do more of that, in a structured way in front of everyone, instead of waiting for a student to ask about it and quickly explain it in person.
It's an event storming workshop so naturally there is a focus on the actual event storming, but the event storming itself isn't worth all that much if you don't know how to turn the mental model of commands, events and business rules into working code. That's why I would keep the event storming exercise a bit shorter (after two hours you get the point) and move on to the rest faster, allowing more time at the end to get into some implementation details. As always, a good example is worth a 1000 (I actually think a lot more than 1000) words.
You train people who code for a living. I am confident pretty much everyone in the room was left wondering how to take the car rental example further, into the realm of the pragmatic. So I think choosing just one of the cases that comes out of the modelling session and take an hour to turn it into pseudo code would boost the value of the workshop enormously.
All in all, well worth it! Thanks!
It was a very good workshop (with actually a lot of work), but the fact that there were three of you had advantages and disadvantages. There were a lot of good additions and comments, but it made the day less structured.
Two things that could come in handy: a flipchart (or a piece of paper), listing the days topics (without actually writing down the technical names) so people now where you're heading (and when you've completed a topic). And a handout in the end with all the vocabulary so people say the correct names/verbs/etc... to other people).
Nicely done!
The DDDBE modellathon was the first time I heard about event sourcing and I liked doing this exercise again. I was great to have 3 people around to ask questions. Thanks!
Very interesting topic, but in the end I found it a little bit hard to follow because of the lack of code examples. The presentation given the saturday after really cleared a lot up for me and it would have been a big help if that was integrated with the course or something.
Very asome tutorial on how to do event storming and to learn about event sourcing. It changed my perspective on data storage and blew my mind away how to loop at domains. I wil start experimenting on domain driven design and development.
I think to have some slides with code or make some implementation example would have helped. We spent a lot of time thinking about answers that were given but later on, but even if it was a guided exercise to come up with answers from us, then it feels like letting the time pass to fill the day rather than actually getting this rapidly so we can cover more material.
The workshop has a lot of merit but I personally think it is easy to turn this workshop into some `agile` conversation which was not very well envisioned by the title. Event brainstorming has part of this but I think perhaps just half of day should be practical the other should be more theory?
It was a fantastic workshop. Having three people to ask questions was a really good move.
My only suggestion for the speaker is to have a look at the timing. We got plenty of time for the first part (generating events) but the parts after that (identifying commands and business rules) felt a little rushed. That can be a bit problematic since creating aggregates relies on having a few good combinations of events/commands/rules on the board.
It was an interesting workshop to attend - it was interesting to experience a different way of modelling from the "classical" strategy of starting with entities and relations. I agree with the anonymous comment made at 2014-06-27 07:21, that a theoretical introduction would have been nice.
The last part of the workshop would have benefitted from a more code-oriented approach. A demonstration of how to turn this into an actual implementation (perhaps using Buttercup as an example) would have made me leave the conference with more confidence that I can actually use this in my daily coding practice.
Very interesting topic, this was the second time I did this workshop but it was changed a little and also very good to refresh my memory. I definitely try this technique (and CQRS). The only reason not to give 5 stars is to prevent Matthias and Stijn from getting lazy ;-) So keep on going!