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.

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

    View full-size slide

  2. Kenny Baas
    Schwegler
    Software Consultant - EventStormer
    Domain Driven Design
    Behaviour Driven Development
    Continuous Delivery
    @kenny_baas
    Baasie.com
    xebia.com/blog/author/kbaas/

    View full-size slide

  3. 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

    View full-size slide

  4. 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

    View full-size slide

  5. DDD puts a lot of emphasis on shared models between
    business, devs, testers, documentation writers, UX.
    - Mathias Verraes

    View full-size slide

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

    View full-size slide

  7. 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

    View full-size slide

  8. 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)

    View full-size slide

  9. 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

    View full-size slide

  10. 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

    View full-size slide

  11. Confirmation Bias

    View full-size slide

  12. The greatest obstacle to discovery is not ignorance -
    it is the illusion of knowledge.
    - Daniel J. Boorstin

    View full-size slide

  13. It is not the domain experts knowledge
    that goes to production, it is the
    assumption of the developers
    that goes to production
    - Alberto Brandolini

    View full-size slide

  14. Big Picture
    Process Design
    and Modelling
    Software
    Modelling

    View full-size slide

  15. 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)

    View full-size slide

  16. Try at least to find three models,
    even if you think you already found
    the “right model”

    View full-size slide

  17. Don’t cling to a mistake
    Just because you
    spend a lot of time making it.

    View full-size slide

  18. Software Development is
    a learning process, working code is a
    side effect
    - Alberto Brandolini

    View full-size slide