After a moderately successful attempt at becoming a professional rock musician, Tobias 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 (domain specific languages, model-driven architecture... and Flash), and eventually decided to focus 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, 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, especially complex distributed systems, with microservices and/or Big Data pipelines, we have to make a series of important tactical decisions regarding the structure and information flow within 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 full architecture 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. This way, we can actually see our design work, and gain valuable insights.
Using examples, I will demonstrate how combining Domain Driven Design with the practices, heuristics and principles of Software Crafting can highlight difficult or problematic choices, improve fundamental architecture decisions, and ultimately lead to better and more sustainable software systems, long before we get sidetracked by the additional complexity of host environments and deployment pipelines.
Our conference is dedicated to providing a harassment-free conference experience for everyone, regardless of gender, gender identity and expression, age, sexual orientation, disability, physical appearance, body size, race, or religion (or lack thereof). We do not tolerate harassment of conference participants in any form. Sexual language and imagery is not appropriate for any conference venue, including talks, workshops, parties, Twitter and other online media. Conference participants violating these rules may be sanctioned or expelled from the conference without a refund at the discretion of the conference organisers.