Kenny Baas is a Software Engineer and Consultant focusing on software quality at Xebia. He mentors and coaches teams by using practices and techniques from Domain Driven Design, Behaviour Driven Development, Test Driven Development, and Continuous Delivery.
He is an advocate for multidisciplinary collaboration in open spaces. By using techniques such as Event Storming, and Example Mapping, he helps engineer requirements to design and model software. With these methods, he aims to create a transparent, collaborative domain space with constant and instant feedback when delivering software.
Besides his daily work, he also helps organise meetups for Behaviour Driven Development NL and Domain Driven Design Nederland.
This is a pre-conference workshop. Click for details.
To really understand what our users will need, we want to have a first-hand experience from 'real-life stories' before we can model and create our software. While both the DDD and BDD techniques 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 based on feature mapping, such as Example 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 which matches the shared understanding of the user, creating a ubiquitous language. Value will be shipped at a faster pace.
In this hands-on session, we start with a Process EventStorming. We will use Example Mapping to get more insights into our process. Eventually, I will show you how the outcome can drive our Software Modelling EventStorming and create Executable Specifications. This way we can create a ubiquitous domain language that we can use in our application and test code. You don't need a laptop for this session as the focus is on the discovery phase.
Every time I start working on a new software product I want to learn the domain. The faster I learn the domain I am working in, the faster I will add value to that product. I always start by looking at the tests; they should reflect what the software is built for and how it needs to behave.
However, the tests seldom reflect the same language as the code, the documentation and the communication. Inconsistent language usually is one of the reasons testing slows down the software delivery process. A lot of ‘ping-pong’ going on between several disciplines and even though the product is rigorously tested, there are still a lot of bugs found in production. It is hard, or even impossible to build the right product if there is inconsistency in the language used to communicate.
Join me in this talk where I will show you how to leverage Domain-Driven Design throughout testing. You will learn how to make the language of your tests consistent with the communication used, and create tests that can serve as living documentation.