While Bruno Boucard, Thomas Pierrain, and I were preparing our DDDEurope 2019 workshop, we discussed how to approach Example Mapping. For the workshop, we were combining EventStorming and Example Mapping to go from problem space to solution space. The way I have been approaching Example Mapping was slightly different then Thomas and Bruno did. Mine followed up more on EventStorming, standing in front of a wall storming examples first with stickies. Bruno and Thomas do it the way that was described byMatt Wynne from cucumber, standing in a group around a table, starting with a user story and one rule written on index cards. So we began to discuss in short what these difference are, and what the trade-off was when we did these. In this post, I will explain the different heuristics on approaching Example Mapping in this post.(more…)
In my previous post, I discussed why we want to write software with empathy in mind; software that is understandable for peers. For us to create software with empathy in mind, we need to create a shared understanding of the users’ needs; the needs we are trying to satisfy with our software. Practices like Domain Driven Design (DDD) and Behaviour Driven Development (BDD) can help us achieve this. By using Feature Mapping (a technique from BDD) and improving this with Event Storming (a technique from DDD), we can create executable specifications and a model for our business needs at the same time. This way, we can write software and tests that match the shared understanding the business has, which enables us to ship more value faster.
One of the biggest challenges as engineers is to write working software and also keep an extensive documentation. Most engineers hate writing documentation, and after they published documentation on a wiki it will die a lonely death. We want to strive for writing a Living Documentation in an Ubiquitous Language. Practices like Domain Driven Design (DDD) and Behaviour Driven Development (BDD) can help you achieve this. Especially when we start writing code, it is really important for the quality of our software to start with tests describing what your application does. We want to write software with empathy in mind, software that is understandable for peers. While software developers are beginning to use the language of the domain (business language) more in their application code, most tests still contain a lot of technical language.
The practise of Behaviour Driven Development (BDD), and using tooling to support this like cucumber, has inspired many posts and talks. The recurring questions are predominantly about how teams and people pull these tools out of its collaboration context, and bring it into the test automation context. Cucumber’s post might perhaps be one of the best on this topic,
Last year I started giving talks about BDD based on my own experiences. One pitfall that always seems to pop up, at least in the Netherlands, is about imperative versus declarative (or implementation vs intention).