Ten Years of DDD Europe - A Conversation with Mathias Verraes

Posted on 2026-03-04 - 9 minute read

This year marks the 10th edition of DDD Europe, the world's premier software modelling and design conference. To celebrate, we sat down with its founder, Mathias Verraes, to look back at a decade of ideas, community, and the occasional near-disaster. The conversation was led by Gien Verschatse, a senior software design consultant at Aardling, and the current curator of DDD Europe.

Gien Verschatse: Taking yourself back to before 2016 when the idea first came about, why did you feel Europe needed its own DDD conference?

Mathias Verraes: At the time there was a conference called DDD Exchange in London. It was a nice small conference. But it was isolated, there wasn’t a real community, apart from a Yahoo group and a few meetups.

I loved how Eric Evans, the author of “Domain-Driven Design” (Addison-Wesley 2003) was so openminded about having the ideas in his book being challenged, which made me want to be a part of this.

In 2013, I started the DDD Belgium meetup which created a lot of enthusiasm, with participants traveling in from neighbouring countries. I felt we needed something bigger, a place where people could gather and new ideas in DDD could have a space.

We're ten years later, this is the 10th edition! You've had a front-row seat to how Domain-Driven Design evolved over that time. What would you say was one of the biggest shifts you've seen?

In the beginning, Domain-Driven Design in people's minds was essentially object-oriented programming done well, design patterns and that sort of thing. Then gradually people started to realise that modelling and language were essential, and then later Strategic Design came to the foreground.

That pendulum did swing a little too far at one point, with some people arguing that tactical design was unnecessary or even harmful. Thankfully, that notion faded. If you take Eric's original book very literally, some patterns are certainly outdated, but it was always about the principles, not the specific patterns. Eric's intention was that DDD should be extended and updated, with patterns and practices being replaced by better ones.

We've seen exactly that. Eventstorming was a significant shift, a different modelling style that moved firmly away from UML and entity-relationship diagrams. And at roughly the same time, Event Sourcing & CQRS emerged as a whole different programming paradigm growing out of the DDD community. Those are probably the two biggest shifts. There’s been ideas like Living Documentation, Design Heuristics, Domain Storytelling, and Residuality Theory, that we started showcasing early on, and other ideas that never got a footing. But beyond specific practices, the overall philosophy of DDD, how to approach software and how to think about it, has gained far wider understanding and matured considerably.

Did you see anything interesting happen when functional programming became more popular?

Yes. Because the original book was rooted in object-oriented patterns, the functional programming community was somewhat dismissive: the feeling was that everything object-oriented was suspect. We even had talks at DDD Europe from people arguing that DDD didn't work for functional programming.

Of course the core principles do work: look at the language, build models that represent the domain, make knowledge explicit. What actually happened, I think, is that functional programming won, not by converting everyone to FP languages, but by seeping into all the other languages. In that sense, it has blended quite naturally with DDD over time.

The conference has grown from a DDD conference into "the world's premier software modelling and design conference." Was that broadening intentional, and what drove it?

It was always intentional from the very beginning. I wanted a place where new ideas in software modelling and design would have a home, where we could uncover them, bring them to an audience, and let the community decide what worked and what didn't. It was never just about promoting DDD. It was about promoting better software quality and design.

There’s many ideas which didn’t originate in a DDD or even a software context, but we put them on the DDD Europe stage, and the DDD community started integrating them as essential parts of what DDD means. We were among the first to look seriously at Cynefin, complexity theory, Wardley Mapping, insights into how systems fail... The community took those and incorporated them into its collective understanding of DDD.

Your own work has also evolved significantly. If you go back to your earliest blog posts, they were mostly about tactical patterns. Now you focus on worldviews and design strategy. How has organising this conference influenced your own thinking?

I have been accused of using the conference as a way to get access to the smartest people in software design! Debating and writing are my favourite learning styles. The people I've met have been extraordinary. I met Rebecca Wirfs-Brock, who became my co-author on “Design and Reality” (self-published, 2022), at DDD Europe 2017. Eric Evans is a close friend, he stays at my home sometimes when he’s in Europe. We talk monthly or so; he's deep into AI internals right now and we discuss how that intersects with DDD and software design. People like Cyrille Martraire or Alberto Brandolini, who’s writing I devoured, have often pushed me to rethink stuff, or Romeu Moura and Xin Yao, who are pretty much the DDD Europe resident philosophers at this point.

My favourite fanboy memory is when I had dinner with Dr. Anita Sengupta, who designed the parachutes for the Mars Curiosity Rover landing, and her friend from the European Space Agency, who was working on sending the Laser Interferometer Space Antenna to measure gravitational waves. I remember thinking that that was probably the closest I’d ever get to going into space!

Another side-effect is that networking at DDD Europe got me to hired more for software design strategy, as opposed to the more technical consulting in my earlier years. With increased opportunity and exposure to people working design strategy, my writing changed as well.

Early attendees said the Belgian DDD community was remarkable. How do you maintain that energy and passion across a decade, as the community has grown so far beyond that original Belgian meetup?

We all felt like pioneers, pushing these ideas as far as we could take them. The very first DDD Belgium event we organised, we did a "modelathon": someone would take the role of the domain expert and we'd model together. That energises the kind of people who like to solve problems together. We still do those kinds of things at DDD Europe.

But honestly, it doesn't feel like an effort to maintain enthusiasm, because there is simply so much interesting ideas that come in. In the early years we had to go searching for it. Now, because people know what this conference is about, a lot of it comes to us. Last year we had over 500 submissions for the programme, now it’s 600. It stays fresh.

The hands-on sessions have always been central to DDD Europe. Was it always the intention to focus more on practice than on sitting and listening?

Yes. When I started the conference, I wanted it to have the best elements from every conference I'd attended. I remember at one conference debating with a friend. We found a whiteboard and just started to draw models. I wanted to create that feeling deliberately, instead of waiting for random chance, or at least give people the opportunity to have it.

So we looked at every possible way to encourage people to meet and interact: hands-on labs with an emphasis on collaboration, whiteboards in the hallways, things like the Pac-Man rule or the conference buddy system.

Learning is also simply better when you're doing rather than only watching. And the hands-on sessions serve another purpose: they work as samplers. Say you've heard about Event Storming but aren't sure it's for you. You wouldn't necessarily commit to a two-day workshop with Alberto Brandolini straight away. But a two-hour session at the conference? You try it, and if it's not for you, that's fine, that's knowledge gained. If it is for you, two hours can be enough to genuinely understand what it's about in a way that no amount of reading about it can give you.

It's worth saying: the people who only watch the recorded talks on YouTube never see what the hands-on sessions are actually like. I think they get a limited picture of what DDD Europe really is, compared to when you're there in person.

After ten years of talks and workshops, are there any that fundamentally changed how you thought about software design?

Quite a few, yes. Although because I'm often doing the research before selecting a talk or inviting a speaker, the world-changing moment has usually already happened for me before the audience sees it at the conference.

Just one example is Sidney Dekker. I read “Drift into Failure” (Routledge 2011) on aviation safety. He’s an expert on how complex systems gradually deteriorate and fail. I found that fascinating, and it’s great to see when his presentation got DDD people interested as well. There’s been many instances like this.

Any disasters or near-disasters in organising these events that you can laugh about now?

Plenty. Every year brings problems: a speaker cancelling, a flight arriving late. We've come to think of those as “normal problems”. But there have been a few moments where the future of the conference genuinely hung in the balance.

The first edition in 2016 happened two months before the terror attack on Brussels Airport. IF that had that happened just before the conference, we would have had to cancel, and the financial loss would probably have ended everything before it began.

The year after that, we moved to Amsterdam and had severe snowstorms, though most speakers made it through in the end. And then the pandemic. We were lucky that our conference happened just before it really hit. When we came back to in-person events afterwards, it turned out we had been the last conference many people attended before lockdown, and the first they returned to after. It felt like a real celebration.

Data Mesh is one of the ideas that grew out of the DDD world and that DDD Europe helped bring to wider attention. How does it feel to watch something like that grow so enormously?

It's wonderful. I remember reading Zhamak Dehghani's first major article on Data Mesh, probably around 2019, and thinking: this is it. This is DDD applied to data. It had a lot of the same thinking, but without trying to map things exactly; it found its own patterns and principles.

I contacted her immediately after reading the article and invited her to speak. She ended up giving her first presentation on the topic at DDD Europe, and in later years came back to run workshops.

At some point it felt like this idea had grown large enough to deserve its own conference. The way I think about it: DDD itself was very small when we started our conference, and I believe DDD Europe had a real impact on its growth. I hope we can do the same for Data Mesh. Tom De Wolf, who leads the programme for Data Mesh Live, is absolutely immersed in it, he's the right person for it.

We've looked back at a decade, now let's look forward. What do you think the emerging challenges will be in software design, and how should DDD Europe help the community tackle them?

There are several ways to look at it, but the obvious answer is AI.

Every time the abstraction level in programming rises, it becomes more accessible, more people can come in. That's how I got into programming myself; I didn't have an engineering degree. But the downside is that more people can produce more legacy software, faster. Whether that matters is an open question, because perhaps AI can also help us fix legacy systems in ways we couldn't before.

Another possibility is that the very concept of software as we know it changes fundamentally: building an app, deploying it, having users, … Perhaps you simply tell an AI to do things for you, and apps as a concept disappear. I genuinely don't know.

But if you take a bird's-eye view, it's still humans telling machines what to do, and needing to know what to ask for and how to express that, and then doing that at high scale and complexity levels. That has always been the essential focus of Domain-Driven Design: understanding what's needed, expressing it clearly, finding ways to make it visible so people can agree and discover what they've missed. There will still be humans interacting with these systems, and that's probably where the real competitive advantage will lie.

Though I'll admit I'm speculating, and I think we're in the same position as in 1998 when Google had just arrived. I was 18 then, very excited about the internet, but nobody could have predicted smartphones, social media, SaaS, crypto, the assault on democracy, mass disinformation, and everything else that followed. Many predictions right now are still looking at the old world and sprinkling some AI on it. That's almost certainly going to be wrong.

Ready to explore DDD Europe 2026? Check out our speakers and program to see who's joining us this year.