Upgrade to Pro — share decks privately, control downloads, hide ads and more …

From EventStorming to CoDDDing @ JFall

From EventStorming to CoDDDing @ JFall

To really understand what our users need so that we can build the right thing, we want to have a first-hand experience of ‘real-life stories’ before we model and create our software. To quote Alberto Brandolini “it is not the domain expert’s knowledge that goes into production, it is the developer’s assumption of that knowledge that goes into production”. EventStorming is a visual technique that minimizes assumptions by engaging in collaborative deliberate learning across different disciplines. This helps to solve complex business problems in the most effective way.

Although the learning of the domain helps us to understand the domain better, EventStorming can be quite an overwhelming experience. Developers can be left with the question of how to turn a few stickies on a wall into working code.

Join us in this talk in which we show the basic principles of EventStorming. We will cover the different forms of EventStorming and in which situation they best can be applied. And, we will show how you can leverage DDD (Domain-Driven Design) patterns in an EventStorming software modelling session that will ultimately result in coding TDD (Test Driven Development) style!

Kenny Baas-Schwegler

November 08, 2018

More Decks by Kenny Baas-Schwegler

Other Decks in Programming


  1. From EventStorming to CoDDDing

  2. Software Consultant - EventStormer Domain Driven Design Behaviour Driven Development

    Test Driven Development Continuous Delivery @kenny_baas baasie.com @joaoasrosa joaorosa.io
  3. None
  4. None
  5. None
  6. None
  7. None
  8. None
  9. The fundamental horror of this anti-pattern is that it's so

    contrary to the basic idea of object-oriented designing; which is to combine data and process together. - Martin Fowler
  10. What's worse, many people think that anemic objects are real

    objects, and thus completely miss the point of what object-oriented design is all about. - Martin Fowler
  11. None
  12. None
  13. None
  14. Confirmation Bias

  15. https://lizkeogh.com/2015/09/09/on-epiphany-and-apophany/ Build beliefs Draw conclusions Generate assumptions Filter data Observe

  16. It is not the domain experts knowledge that goes to

    production, it is the assumption of the developers that goes to production - Alberto Brandolini
  17. The greatest obstacle to discovery is not ignorance - it

    is the illusion of knowledge. - Daniel J. Boorstin
  18. To communicate effectively, the code must be based on the

    same language used to write the requirements - the same language that the developers speak with each other and with domain experts - Eric Evans
  19. We all know or should know that language is fluid,

    liquid, subject to the whims of the people. Language evolves, as it should. Because language changes to accommodate new users, the older users resist and complain. http://tednellen.blogspot.com/2013/04/language-is-fluid.html
  20. None
  21. None
  22. None
  23. None
  24. None
  25. Big Picture Process Design and Modelling Software Modelling

  26. None
  27. None
  28. None
  29. None
  30. None
  31. None
  32. 1. Protects business invariants 2. Design them small 3. Reference

    other by ID only 4. Update other using eventual consistency
  33. Try at least to find three models, even if you

    think you already found the “right model”
  34. None
  35. None
  36. Software Development is a learning process, working code is a

    side effect - Alberto Brandolini
  37. Serious software development is the practice of symmathesy. “Sym” =

    together, “mathesy” = learning. - Jessica Kerr
  38. #CatTax