Creating multiple models for the same problem is one of the more important lessons that Domain Driven Design teaches us. It is a lot cheaper to quickly iterate over them and throw away less useful prototypes before we even start coding. However, creating multiple models can be hard. When we begin gaining insight from our domain, we suffer a lot from cognitive biases that get in our way to gain new insights. We need these insights before we even start thinking about modelling. Tools like event storming and example mapping can help us to deliberate discover, and battle these biases. They help you quickly gain insight into the problem space. But the fallacy here is that we can get locked into the tool, and get stuck again. What you will learn

In this two day workshop, you will learn the essentials of event storming and how it can help you gain the necessary insights you need to deliver quality software. With our newly acquired domain knowledge, we can then start exploring the solution space. During the exploration, we begin to design and model multiple models for the same problem with Domain Driven Design patterns. This way of visualising gives us the power to quickly iterate over the different models and figure out which model will be the best to use for now. Eventually, we start our coding journey TDD style, iterating over the model to refactor towards deeper insights while discovering how hexagonal architecture may help us to protect our domain code from the technical concerns, in the long run. Target Audience This workshop is for you if you are a software architect or software developer. Program

Introduction
Domain Driven Design a brief tour
Event Storming - essential workshop
Example Mapping - essential workshop
Discovery Phase: Process Modeling Event Storming / Example Mapping
Recap

Technical DDD patterns
Software modelling
Test-first coding flow (from problem space to solution space)
Hexagonal architecture overview and implementation
Refactor towards deeper insights
Recap

Read the free ebook The Anatomy Of Domain-Driven Design: https://leanpub.com/theanatomyofdomain-drivendesign
It is nice to have read Domain Driven Design by Eric Evans (the blue book), it is not required.
Able to properly remove a sticky note
For the second day: Bring a laptop with your favourite IDE and programming language

Kenny Baas-Schwegler 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.

Bruno Boucard is developer, trainer, agile coach and speaker. He loves to explain with concrete examples with live-coding, if needed. He is organizer of the BDD Paris user group. He is a long-time Microsoft MVP, but he still is coding java with a C# accent ;-)

His company 42skillz which aims to help organizations to make software and to work differently, he provides trainings, coaching, consulting about TDD, BDD, legacy code refactoring techniques and DDD with an extra soul.

Thomas Pierrain is co-organizer of the DDD Paris user group and co-founder of 42skillz, Thomas is an eXtreme Programmer & technical architect obsessed by use cases (Vs. solution-driven approaches). He likes using DDD & TDD to boost his efficiency at work.

Polymath wanna be, Thomas loves to inspire his work with philosophy, astrophysics, psychology and music (to name a few).