When it comes to "paint-drip people", Tobias is a good example: After a moderately successful attempt at becoming a professional rock musician, he started his career as a freelance web developer in 1997, and has since worked on hundreds of smaller and larger projects, from a few days to several years, in a variety of roles, contexts, and industries. He is a survivor of no less than three major technology hypes in fundamentally different areas (domain specific languages, model-driven architecture... and Flash), and has since focused on topics with a less volatile lifespan - Lean, Agile, Software Crafting and DevOps.
Having found a home as a consultant, crafter and coach at codecentric in 2014, he strives to help customers to build and improve not only their product, but also how it is made.
He is a passionate advocate for collaborative work environments, knowledge sharing, and diversity, and a co-organizer of SoCraTes Germany (https://socrates-conference.de/).
Tobias is a father of two and loves music, books, movies, and little dogs.
When we design a system from scratch, we have to make a series of important tactical decisions regarding the structure and information flow of our domain. If we assume boundaries in the wrong place, or forget or omit important aspects of communication, we can end up with brittle services, performance issues, and needlessly coupled modules and components, which are painful to maintain and deploy.
Some of those aspects are hard to discover upfront, and even with great experience, it's not unusual to get the first design at least partially wrong.
One way to minimize the consequences of those decisions, and to verify our initial assumptions, is to start implementation not with a complete design in mind, but rather with the smallest possible footprint: A plain, but fully operational prototype of the domain model, which we can stress, observe and explore - and change easily, if we run into problems.
In this workshop, we will use a suite of automated BDD tests -- the result of fictional EventStorming and ExampleMapping -- to implement and evaluate our domain model, gain insights into its behavior, and improve and evolve the design, according to our learnings.
You will need a laptop and IDE with a running installation of NodeJS.