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

Crunching 'real-life stories' with DDD EventStorming and combining it with BDD techniques @ Lean Agile Scotland

Crunching 'real-life stories' with DDD EventStorming and combining it with BDD techniques @ Lean Agile Scotland

To really understand what our users will need, we want first-hand experience from 'real-life stories' before we can model and create our software. While both the DDD and BDD techniques place emphasis on ‘real-life stories’ by doing collaborative, deliberate learning, they both focus on different goals.

DDD focuses more on creating bounded contexts in which a single model is created; BDD focuses more on different scenarios and can create executable specifications as an outcome. By doing EventStorming and using techniques from BDD, such as example mapping and feature mapping, we can create more insights. We can simultaneously create a model and executable specifications for our user needs. This way, we can write software and tests that match the shared understanding of the user, creating a ubiquitous language. Value will be shipped at a faster pace.

In this session, I will explain how to do process EventStorming. We will use example mapping and feature mapping to get more insights into our process. The outcome can drive our software modelling EventStorming and create executable specifications.

01abe62e641a626ed2dccc08ea2f8a14?s=128

Kenny Baas-Schwegler

October 04, 2018
Tweet

More Decks by Kenny Baas-Schwegler

Other Decks in Technology

Transcript

  1. Crunching 'real-life stories' with DDD EventStorming and combining it with

    BDD techniques
  2. Kenny Baas Schwegler Software Consultant - EventStormer Domain Driven Design

    Behaviour Driven Development Continuous Delivery @kenny_baas Baasie.com xebia.com/blog/author/kbaas/
  3. None
  4. None
  5. None
  6. None
  7. None
  8. None
  9. None
  10. Any organization that designs a system (defined more broadly here

    than just information systems) will inevitably produce a design whose structure is a copy of the organization's communication structure - Mel Conway
  11. None
  12. None
  13. None
  14. None
  15. Questions about whether design is necessary or affordable are quite

    beside the point: design is inevitable. The alternative to good design is bad design, not no design at all. — Douglas Martin
  16. DDD puts a lot of emphasis on shared models between

    business, devs, testers, documentation writers, UX. - Mathias Verraes
  17. None
  18. None
  19. None
  20. A straight line between 2 points corresponds to a compass

    direction in reality..
  21. A straight line between 2 points corresponds to a compass

    direction in reality.. • Except for points located in Greenland • Except for points located in Africa
  22. All models are wrong, but some are useful, and some

    are useless, and some are outright damaging. Sometimes a model only gives you the illusion of control. - Multiple people (Attributed to George Box)
  23. None
  24. None
  25. 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
  26. None
  27. None
  28. 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
  29. None
  30. Confirmation Bias

  31. The greatest obstacle to discovery is not ignorance - it

    is the illusion of knowledge. - Daniel J. Boorstin
  32. None
  33. None
  34. None
  35. It is not the domain experts knowledge that goes to

    production, it is the assumption of the developers that goes to production - Alberto Brandolini
  36. None
  37. None
  38. None
  39. None
  40. None
  41. Big Picture Process Design and Modelling Software Modelling

  42. None
  43. None
  44. None
  45. None
  46. None
  47. None
  48. None
  49. None
  50. None
  51. None
  52. None
  53. None
  54. None
  55. None
  56. None
  57. None
  58. None
  59. None
  60. None
  61. None
  62. None
  63. None
  64. None
  65. None
  66. None
  67. None
  68. None
  69. None
  70. All models are wrong, but some are useful, and some

    are useless, and some are outright damaging. Sometimes a model only gives you the illusion of control. - Multiple people (Attributed to George Box)
  71. Try at least to find three models, even if you

    think you already found the “right model”
  72. Don’t cling to a mistake Just because you spend a

    lot of time making it.
  73. None
  74. Software Development is a learning process, working code is a

    side effect - Alberto Brandolini
  75. #CatTax