From EventStorming to CoDDDing @ Techorama

From EventStorming to CoDDDing @ Techorama

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. During a live EventStorming software modelling session, we will show how you can leverage Domain-Driven Design patterns that will ultimately result in coding TDD (Test Driven Development) style!

github: https://github.com/joaoasrosa/xpirit-magazine-from-eventstorming-to-coddding

01abe62e641a626ed2dccc08ea2f8a14?s=128

Kenny Baas-Schwegler

October 02, 2019
Tweet

Transcript

  1. 1.
  2. 2.

    2 Strategic software delivery - Domain-Driven Design - Continuous Delivery

    - Socio-technical engineers - Collaborative modellers and facilitators
  3. 3.
  4. 4.
  5. 5.
  6. 6.
  7. 7.

    7

  8. 8.

    8

  9. 9.

    9

  10. 10.

    10

  11. 11.
  12. 12.

    12

  13. 13.

    13

  14. 14.
  15. 15.
  16. 16.
  17. 17.

    17

  18. 19.
  19. 20.

    20

  20. 21.
  21. 22.
  22. 24.
  23. 25.

    25

  24. 26.
  25. 27.
  26. 28.
  27. 29.

    29

  28. 30.

    30

  29. 31.
  30. 32.

    32

  31. 33.

    33

  32. 34.

    34

  33. 35.

    35

  34. 36.
  35. 37.
  36. 41.

    41

  37. 42.

    42

  38. 43.

    43

  39. 44.

    44

  40. 46.
  41. 47.

    47

  42. 50.
  43. 52.

    52

  44. 53.

    53

  45. 54.
  46. 56.

    56 ➔ Using models for creating software ➔ Focus on

    part of the software handling complex business requirements ➔ Focus on a language where we really crisply concisely describe the situation in the domain ➔ Shared language created through conversations between business people (specialists) and software people which becomes the ubiquitous language ➔ Instead of one canonical language, create multiple bounded languages
  47. 57.

    57

  48. 58.

    58

  49. 59.
  50. 60.