Most products start with an initial software model, a model that is usually naive and superficial, based on shallow knowledge. Which makes sense, because you just started discovering and exploring that new product. So we typically start by identifying nouns and verbs and using these as the initial objects and methods to build in our code. While the initial model helps you start getting fast feedback for your product, once you get more feedback most of the time it isn’t a helpful model anymore. They usually don’t provide a rational expression of the primary concerns of the domain experts anymore as time progresses to build that product. Not having that expression can hold you back from making essential breakthroughs for your product, breakthroughs that can be the differentiation factor in the market. And even worse, implementing the model in code might not even support making these new breakthroughs.

Join us in this hands-on modelling and coding session focused on the significance of continuously refactoring your product's core domain model. We will introduce you to the context by guiding you through several collaborative modelling techniques such as Eventstorming, Domain Storytelling, Context Mapping, CRC-cards and more. Dive into coding challenges using C# and Java, where you'll witness firsthand the transformative power of supple design and a deeper model. By the end, you'll understand how continuously refactoring the model can be pivotal in driving product development breakthroughs. Whether you prefer pairing or ensemble programming, you'll depart with enriched practical insights and a deeper understanding of chapter 13 from the blue book by Eric Evans.

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

Whereas Example Mapping is the less known approach of BDD, it is probably the most powerful technique from that field. No Gherkin here, no automation yet. Pure and simple structured conversations that will foster a crystal-clear vision in every developer’s head.

If you were thinking so far that BDD was equal to 3 amigos meetings or given/when/then, you should come to our workshop in order to discover the real “essence” of BDD.

In this workshop, you will learn everything you need to know to get yourself up and running and comfortable with Docker.

Come as you are with your laptop, isn't necessary to have knowledge about Docker with Windows Containers or with docker on Linux. The aim is to discover with examples what's going on about containers and how to leverage it in your developer life.