My experiences at KanDDDinsky 2024

At Senacor, we know that understanding the business problem domain is just as important as crafting exceptional software solutions. Domain-Driven Design (DDD) provides powerful tools to align systems with the organizations they serve, and KanDDDinsky 2024 in Berlin was a fantastic opportunity to explore this further for our colleague Dr. Frederic Chill. Over two days of talks, hands-on sessions, and an open space day, the conference showcased insights into DDD, Team Topologies, and modern system design—all in a collaborative and inspiring atmosphere.

The core of our job as developers at Senacor is delivering solutions that optimally fit our clients‘ needs. This involves excellent software craftsmanship concerning methods as well as outcomes. However, to my mind, this is merely a prerequisite. In my daily work, I perceive that examining and structuring the problem domain of the business challenge we are tackling to be an equally decisive factor for our development team’s success. 

Domain-Driven Design (DDD) provides approaches to address this challenge, particularly within its Strategic Design facet. Based on the original introduction in the book ‚Domain-Driven Design: Tackling Complexity in the Heart of Software‘ by Eric Evans in 2003, a lot of further ideas and methods have been explored. Today, we may pick from a treasure trove of proven tools and knowledge to better align the systems we build with the organizations they are intended to support. To navigate, evaluate and practice these techniques, visiting a suitable conference and interacting with the experienced members of the community is a great idea. 

This year, I had the opportunity to attend KanDDDinksy in Berlin, held at a fitting venue with a view of the Spree River. The conference spanned two days of talks and hands-on sessions, followed by a day dedicated to open space. Everything was well-organized, with the open space day turning out to be packed with interesting content. All sessions were well attended but never overcrowded. Domain-Driven Design and Team Topologies were central topics, but the conference catered to anyone interested in the modern design of software systems and the social systems that surround them. 

The audience consisted largely of software developers, architects, and a few coaches, but notably few people from the business side or non-technical consultants attended. Most participants were from various locations across Europe. If you enjoy reading books or listening to (German) podcasts about software architecture or system design, be prepared to meet some of your heroes at the conference 😉 

A special highlight was the live performance by the LINEBREAKERS, who rocked the stage during the evening reception, singing about the joys and sorrows (JavaScript) of being a developer. 

This year’s keynote was delivered by Vaughn Vernon, author of „Implementing Domain-Driven Design“. In his talk, he advocated for software that is not only resilient but also incorporates recovery mechanisms with a user experience-first approach. He reflected on the architectural challenge of where to implement these mechanisms: Following the single responsibility principle, any component should focus on its core task, rather than implement fallbacks for every potential issue. Vernon presented an approach that involves wrapping components in proxies to delegate meaningful error handling to a specialized supervisor. Presenting clear strategies and even detailed architectural diagrams was a welcome surprise in a keynote. 

A notable talk aimed at sharing experiences was delivered by Michael Plöd. He shared his experiences implementing Team Topologies in various environments. He found that while many concepts from this approach worked well in real life, there were also challenges. An important issue was that teams and their interactions were labeled with Team Topology terms, but these profiles were not sufficiently sharpened. This led to poor performance, as nothing really changed besides the labels. New boundaries had to be set for the teams responsibilities to prevent burnout. 

Rebecca Grier gave an insightful talk on applying scientific studies about human cognitive abilities to the design of technical systems. As this field was completely new to me, I learned a lot. Her conclusion was that our goal should be to place our users in a state of „appropriate trust.“ Users should gain an understanding of a system’s inner workings, feeling more in control while also recognizing its limitations. I found this intriguing as it somewhat contradicts UX approaches that aim to be as reduced and easy as possible. 

My personal highlight was the talk by Julien Topçu and Thomas Pierrain, where they introduced the architectural concept of „The Hive.“ Based on hexagonal architecture, it addresses the issue of microservices being cumbersome in the early development phases before they can be fully leveraged as independent units in a large-scale production system. This topic resonated with me from personal experience. The slide deck was impressively crafted in an 80s neon design, adding an artistic touch to the talk. I urge you to check it out once it’s released on the official channel. 

As a hands-on session, I participated in Kenny Baas-Schwegler’s workshop on Collaborative Software Design. He provided materials, mostly diagrams detailing the software system, and divided the audience into groups of about six people. The goal was to include a new feature that didn’t fit into the architecture in an obvious way. While I expected him to facilitate a specific modeling technique, the teams were given considerable freedom in their approach. This proved beneficial, as I learned extensively from my teammates and together, we developed a suitable solution. In fact, we identified two solutions, leading to an instructive discussion about their pros and cons. One of them featured an additional direct connection between components which added complexity to the communication patterns, technical as well as between teams. On the other hand this saved one of the components from assuming a proxy role for data foreign to its domain. 

KanDDDinsky offers a diverse array of activities, each with its own scope, style, and format. From engaging lectures and experience sharing to live coding and loosely guided hands-on sessions, all experiences were of high quality and hard to compare to each other. For me, this led to a more enriching conference compared to others, where standout talks often overshadow the impact of the rest. 

KanDDDinsky is not a collection of lessons on DDD. While the hands-on and live coding sessions are excellent opportunities to refine your skills with DDD practices, books, courses, and practical experience are more effective if learning DDD is your primary goal. On the other hand, since this isn’t an „expert DDD course“ no prior knowledge is strictly necessary for the conference, although having some background can make certain talks more valuable as you relate them to your own understanding and experiences. 

All things considered, I highly recommend the conference to anyone working on projects involving software system design. KanDDDinsky provided me with crucial insights and tools for my future collaborations with our client’s domain experts and architects.