Domain-Driven Design Europe 2022 Conference

Tackling the Complexity in the Heart of Amsterdam !


Mufrid Krilic

About the conference

DDD Europe made a return to the physical format this year after last year’s online edition. Even though the online format was very much up to the high standards, this year we enjoyed a familiar welcome again in Meervart Theatre in Amsterdam. Once more it was sold out with more than 700 attendees in total and with a long waiting list of all those who wished to learn more about Domain-Driven Design (DDD).

The conference had a week-long program with full-day workshops on the first two days of the week, followed by the “DDD Foundation” one-day conference consisting of introductory topics aimed at curious newcomers to DDD. The last two days of the week were dedicated to the main conference talks and hands-on workshops, which is the topic of this post.

In the next sections I will try to present the highlights from the talks and workshops I attended including some off-the-stage conversations I enjoyed with some old and new friends from the community.


A Commune in the Ivory Tower? - A New Approach to Architecture

Andrew Harmel-Law, Diana Montalion, Mike Rozinsky, Gayathri Thiyagarajan and Dan Young

The heartbeat of the opening keynote was introducing a concept of the Advice Process to integrate architecture perspectives into everyday routines of the development teams. Instead of risking having an architect or architecture team becoming a bottleneck in the company's decision process, the advice process lets the people involved take ownership and implement the decision. All that is required is to seek advice from the persons that might be affected by the decision and the persons with the most expertise on the subject.  

It was a joyful experience to see that the advice process is being advocated by the DDD community, as at CoWork we have already implemented a similar process described by Frederic Laloux in his book “Reinventing Organizations”.

The talk itself was a display on how to do interactive presentations! It included several breaks where we could discuss proposed topics with the person in the next seat, along with answering many surveys. The presenters have dutifully gathered the results and presented them in a Miro board.

Functional Aggregate Design: Processes, Temporality & Automata Theory

Thomas Ploch

A code-oriented talk discussing the concepts of time when modeling aggregates. An aggregate cannot be modeled correctly without taking into consideration a complete life cycle of the domain concept being modeled. Thomas suggests using final state machines and functional mindset when modeling aggregates. Even though the talk was rather technically demanding, I applaud the presenter for challenging the audience as this is one of the most common modeling issues we face when trying to do DDD.

DDD in Product Land

Alberto Brandolini

Another inspiring talk by Alberto, this time on combining product design thinking with DDD approach. The challenge arises when using DDD for product design where user diversity is substantial, and a domain expert and hers/his renowned mental model is not so easily discovered. Alberto suggests focusing on tight feedback loops both to learn quickly about the users and as the main tool to ensure design integrity in our products. One of the key takeaways is the difference between Surface Language/Model and a Ubiquitous Language/Model, the former being the primary user feedback channel. By accepting that, we embrace both models co-existing with each other and consequently translate between them in our systems.  

Critically Engaging with Models

Rebecca Wirfs-Brock, Mathias Verraes

The closing keynote of the first day taught us to compare different and preferably conflicting models before adopting and choosing the model for the problem at hand. A DDD practitioner commonly notices that models are everywhere. In this session though, we were asked to accept that models could have a very constraining influence on our thinking, as each model comes with its own belief system and a set of values. We need to be aware of this and turn our “model alert” on when looking at domain, organizational or technical challenges. In the meantime, Mathias and Rebecca have published the content of their keynote as an article.  

The Fractal Geometry of Software Design

Vladik Khononov

As part of the work on his upcoming book Vladik previewed some of the more innovative concepts in the opening keynote of the second day. In particular, he linked the idea of systems that govern the world of physics being applicable to the world of software design. One such system is the Energy Supply Network, which is sustained by the transport of energy through hierarchical networks. Examples being cities, human beings and organizations! According to Vladik, the energy supplying the software systems is knowledge and especially shared knowledge across the boundaries in the system that results in different types of coupling. We learned that the systems grow either sub-linearly or super-linearly. An instance of the last category are the cities where doubling of size requires more than linearly doubling in interconnections. The same goes for complexity in software systems which grows super-linearly, but the core of the problem of being able to deal with the complexity is that our cognitive capacity remains pretty much constant.  

To turn complexity growth from super-linear to sub-linear Vladik suggests using Fractal Modularity, which measures the distance between components in the software system vs. integration strength. The distance itself is directly related to components being within or without Bounded Contexts. The benefit is knowing when to apply approaches such as loose coupling, looking for low strength and high distance, and high cohesion, looking for high strength and low distance. Suggested reading is the book Scale by Geoffrey West providing ground for some of the ideas in this talk.

Sociotechnical Systems Design for the “Digital Coal Mines”

Trond Hjorteland

By continuing his journey into the research on sociotechnical systems Trond provides ever more insight for the DDD and agile community. The topics covered have only recently been discovered by the communities, yet they seem to have been thoroughly examined by the academia a long time ago. One such example is the term socio-technical itself, which stems from the research from the 60s and 70s teaching us that there is some very firm empirical ground for building organizations around autonomous and self-organizing teams. Trond suggests that there is no need to repeat the experiments and linger in centralized structures but to perform the reorg quickly and then let the continuous improvement and learning happen in the teams as they evolve further. For more reading check out this article by Trond.


Independent Service Heuristics: a rapid, business-friendly approach to flow-oriented boundaries

Matthew Skelton, Nick Tune

This talk belongs to the category of unexpected ones, as we were presented with the DDD approach to helping an organization in a complex domain that did not employ the common collaborative modeling techniques of DDD. Matthew and Nick walked us through a use case where they applied what they labeled as service heuristics: sense-check, brand, revenue/customer, cost tracking, data, personas, teams, dependencies, impact/value and product/decisions. These represent rules of thumbs for identifying candidate value streams (see Team Topologies) and domain boundaries by seeing if they could be run as SaaS/product.  

The challenge of DDD is that it was not intended to work in fast flow environments and that the terminology could work against its adoption. The goal is to engage the stakeholders and to provide rapid feedback on our assumptions about offering something as a separate product or SaaS. To achieve this we can borrow inspiration from product and design thinking and combine it with architectural concerns.


Technical Coaching with the Samman method

Emily Bache

I was quite excited about this talk having been practicing technical coaching myself for many years. Emily showed a simple and practical approach on how to raise the technical competence and deal with technical debt in a team. The Samman (Swedish: together) method has basically two parts: Learning Hours and Ensemble Working.  

The Learning Hours is used for experiments, katas and learning new concepts while Ensemble Working is a new, and better, name for Mob Programming. The latter is a high-effect method that can engage the whole team and spread the knowledge “just by starting to look at someone else typing code”, as Emily puts it. The Samman method can be expanded with more focused coach-led sessions and workshops where teams get to do the work to get technical debt under control. During the talk we were asked to be wary of the danger that iterative and incremental work, as in Scrum, could lead to technical debt! This calls for more technical coaching and Emily is building a community to get more people engaged.


Categorization, Comparison and Cases

Einar Høst

The most entertaining talk of the conference belonged to Einar Høst and his unique way of showing that real world concepts can be modeled only if we accept many different perspectives at the same time. Einar guided us through Category Theory and often counterintuitive conclusions on what categories real world things belong to! It is modeling that helps eliminate ambiguity and handle edge-cases. However, when we create models, we are paying a price for precision in the form of accumulated assumptions in the model over time. To avoid this to result in systems that are hard to change, modeling from different perspectives is an activity that needs to be practiced and is teachable as such.


Design for Humans: How to Make Better Modernization Decisions

Indu Alagarsamy, Olivia Cheng

The closing keynote was a real-time story on how design thinking can help when different roles collaborate on an IT-modernization journey. Even though we do use-cases workshops and Event Storming sometimes it could be hard to follow-up on that with value-added activities. Olivia and Indu presented a set of heuristics that combine experiences from UX-design and DDD in order to help the project reach the next level. It includes service blueprinting, structured user research and Wardley maps. Because organizations exist to serve the needs of humans, the systems that we build should serve the needs of humans as well.



Does culture impact software design?

Kenny Baas-Schwegler, Avraham Poupko

A highly engaging workshop where we discussed connections between the meaning of culture in a broader sense to specific design choices we make as software developers. As being part of a culture is multifaceted, since we all belong to different groups at the same time, this sets the context for the decisions we make.  

The format itself was very dynamic with group discussions interleaved with thoughtful observations by Avraham along the way. One example is a comparison of persons speaking multiple languages with being able to program in several languages, both being features of an open-minded personality. I wish we could have had more than the allocated 2 hours for the workshop to really get deep into this inspiring connection between culture and software design. Kenny was great in keeping the flow of the workshop using this Miro board.



I was happy to meet some old friends after a couple of years of remote-only collaboration, such as Stefan Hofer from WPS in Hamburg, Germany, who, along with Henning Schwentner, authored the book on Domain Storytelling. As I made a humble contribution to the book by supplying a review and an endorsement, Stefan pointed out that several of the people that were mentioned in the book were present at the conference. One of them was a colleague of Stefan, Jörn Koch who introduced me to a very interesting technique called Scenario Casting. Jörn has published a short introduction  and I will surely try to apply Scenario Casting in one of my projects as the first opportunity arises!

Conclusion and Takeaways

What we could witness at the conference is that the DDD community is on the verge of a shift in its mental model. One of the main strengths in the community is that it has always been open to new ideas and approaches even though they might not be directly related to the field of software development. This year it seems that DDD is taking a firm step towards a broader audience, with talks that try to connect the ideas from product management and UX-design with principles from DDD. We could even hear the stories from the successful complex projects out there that opted not to use several familiar DDD techniques most of us take almost as a default choice.

I believe that this shows a level of innovation and curiosity in the community that makes it truly an exciting time ahead for Domain-Driven Design practitioners.

Behov for hjelp med din digitale produktreise?
Vi tar gjerne en kaffeprat!