My name is Kostas Stroggylos and I am a Senior Software Engineer, acting as the tech lead for the team building the Restaurants and Internal Tools at e-food. During the last week of January I had the pleasure of attending the Domain-Driven Design Europe 2019 conference in Amsterdam. It was two exciting days filled with exchanging ideas with practitioners and fellow meetup organizers from all over the world, drawing models with strangers, trying to uncover DDD Borat’s identity, taking sketchnotes and using a lot of post-it notes. Now that the excitement has settled, I want to share some of the highlights and takeaways from this event.
Day 1
For those not familiar with the term, DDD is an approach to software development for complex systems that focuses on the domain model and ensures that the latter is reflected in the implementation. The term was coined by Eric Evans, author of the seminal book on the topic (the “Blue Book”), who also gave the opening keynote speech. A lot has happened in the past 15 years since the Blue Book was published, so Matthias Verraes opened the day surprising Eric Evans on stage with a new book, Domain Driven Design: The first 15 years. It is comprised of 15 articles by various authors and is freely available here.
Eric Evans in his keynote attempted to give a definition of DDD, claiming it lies somewhere in-between mathematics and happiness. He described microservices as the biggest opportunity and risk the software engineering community has had in a long time. In order to avoid negative connotations on “legacy” systems and avoid throwing away their value he suggested exposing assets through them so that they can participate in microservice protocols. This is something we have been doing for a while at efood as we are moving more and more into microservices.
Adam Tornhill described his method for leveraging data from code repositories to uncover areas in the codebase that may indicate issues like excess complexity and indirect dependencies. He then proposed the refactoring of problematic areas in isolation to reduce accidental complexity before moving the improved code back into its original location, taking the chance to write tests in the language of the domain. As refactoring is a big part of the work we do daily, this was one of the most interesting talks for me.
Cyril Martraire delivered one of the most energetic talks, discussing… Digital Transformation 🙂 . The “DDD guy from Paris” went through more than 250 slides to justify why our modeling should be guided by basic principles. The key takeaway is that we need to conceptualize a domain model as a theory, identify the first principles behind it, and challenge these principles to suggest changes in the business processes, leading to innovation. Otherwise we are left with solution envy, a state where everyone wants to be the self-appointed ‘problem solver’.
Nataliya Remez gave an insightful talk about how to transform teams so that they deliver better outcomes rather than increased output. An example that hits home for Delivery Hero is modeling a feature such as pizza – pizza is an output, but we should target a quality outcome: delivering pizza warm, on time, just like the customer wants it. She concluded that Product Strategy is a hypothesis that needs to be validated and refined continuously by collecting measurable signals, and this is something our POs strive to do daily.
The closing talk I chose for the day was given by Jérémie Chassaing. He discussed time and its effects on business from centuries ago up until now. The thing to keep in mind is that concurrency issues are (or should be) mostly business decisions, not technical ones. We need to solve issues from the business rather than the technical perspective. Doing things asynchronously is often better than blocking things, waiting until we have all the data available to make a fully informed decision.
Day 2
One of the themes of the conference is that you can get together with other people and design models of any kind. The organizers try to promote this practice with hands-on workshops and by setting up whiteboards in all public spaces and creating a modeling challenge as a competition during the conference. This helps enormously with socializing as ad-hoc teams form and people collaborate towards a common goal. Another thing I appreciate immensely is that it’s not just talks – there are numerous 2-hour hands-on sessions taking place simultaneously where you can put all that modeling knowledge into practice. This was a great experience since I typically use drawings and models for better communication within my team.
The second day started with Maaret Pyhäjärvi discussing how testing mentality can help break our illusions about the systems we build. She described some illusions we have about the code we write and the products we build, and analyzed how cognitive dissonance, a term I had come across when reading Black Box Thinking by Matthew Syed, can lead to them. She then offered some heuristics to break them, and presented one of the most discussed slides in the whole conference, containing a controversial opinion on what continuous delivery means.
The better part of the second day involved two hands-on sessions. Marijn Huizendveld ran the first one, where we built teams of 5 to 6 people and were tasked with building a model for a fictional car rental service in Amsterdam. The biggest lesson was that you can always throw away the first version of a model, since it’s bound to be far from perfect. It’s crucial to iterate as one learns more about the domain, and visualization is key to creating a refined model version. This is something I practice and encourage in my team, and it explains why we spend so much on post-its and whiteboard markers :).
Nicole Rauch ran the second hands-on, where the task was again completed in a team of 5-6 people and was to use Event Storming in the context of a fictional retail e-shop. Event storming is one of the most recently developed techniques for collaborative domain modeling. Its effectiveness stems from bringing people that have the questions (typically: developers) in the same room with people who have the answers (typically: domain experts, a.k.a. “business” people), and aligning their perspectives on how the organization operates – or should operate. You just need to make sure you have lots of post-its at hand before starting.
The conference concluded with Dr. Anita Sengupta, a rocket scientist and aerospace engineer, who talked about the past and future of human exploration of Mars. Extremely passionate and energetic on stage, one can admire how driven she is. The key takeaway from her speech for me was that a serious challenge, like sending people to Mars, is crucial to provoke out of the box thinking that will leverage past knowledge to push the boundaries of technology. That is the reason I enjoy challenges at work!
Closing thoughts
My experience consolidated the expectations I had about DDDEU being one of the most interesting conferences. It focuses on the sociotechnical aspects of building software systems – after all, “Software development is a technical activity conducted by human beings” according to Niklaus Wirth. As Andrea Goulet eloquently put it, “What I love most about DDDEU is that it’s actually a philosophy conference disguised as a tech conference”, so it will definitely be at the top of my list for the coming years.
