Too Many Islands, Too Few Bridges: Notes from the Event Modeling Conference 2026 - EventSourcingDB

Skip to content

Initializing search

Getting Started

Fundamentals

Deployment and Operations

Reference

Client SDKs

Extensions

MCP Server

Best Practices

Implementation and Development

Data Management and Performance

Operations, Compliance and Infrastructure

Common Issues

Blog

Categories

Privacy Policy

Legal Notice

Too Many Islands, Too Few Bridges: Notes from the Event Modeling Conference 2026¶

Every once in a while, you walk into a room and feel a particular kind of energy: the sense that a community is standing at the edge of something larger than itself. The first time I experienced this was in September 2011, in Brescia, at the first Node.js Conference Italy: around 250 people from across Europe, convinced they were looking at the next big thing in server-side software. I wrote an article about it back then , every bit as caught up in it as the people around me. As it turned out, we were right.

The second time was last week, in a converted industrial space in Munich, at the two-day Event Modeling Conference 2026 , with around forty other people. The same restlessness, the same sense of momentum. And one question that kept resurfacing all day, in talks and in hallway conversations alike. By the end of the second day, that question had a name, scribbled across a flip chart and signed by nearly everyone in the room.

Golo Roden at the Event Modeling Conference 2026

Forty People in a Room in Munich¶

The conference took place at the Impact Hub Munich, a former industrial site with exposed concrete and a comfortably improvised feel. It was sold out, yet still small enough that you could realistically meet everyone over the course of two days. Nebulit organized it, and Martin Dilger held the whole thing together as host, something he did remarkably well.

The format was deliberately varied: keynotes, talks, hands-on workshops, open-space sessions, and a marketplace of short pitches, all woven together across the two days. What I appreciated most was how much breathing room there was around the sessions. Between talks, there was more than enough time to network and, just as importantly, to disappear into a side room with a handful of people and dig into a single topic in a small circle. People used that opportunity eagerly, and some of the best moments of the conference happened in exactly those side rooms.

The conference revolves around Event Modeling, the method Adam Dymitruk has done so much to shape: a way of describing how information flows through a system over time, blueprint-style, before a line of code is written. If you want a gentler introduction to the idea, we explored it in an interview on Event Modeling a while ago. Adam opened the conference with a keynote. Unfortunately, he couldn't be there in person and had to join by video. We spend a fair amount of time at gatherings like this; not long ago we wrote about our first KanDDDinsky . But this one had a different texture, and most of it came down to a single, nagging question.

Too Many Islands, Too Few Bridges¶

That question, in one form or another, was this: why is it still so hard to find your way into this field?

Because the field that calls itself Event Sourcing, CQRS, and Domain-Driven Design isn't really one field. It is an archipelago. There are many schools and many flavors of how to do this work. Do you model with aggregates or with dynamic consistency boundaries? Do you do Event Storming, model using Event Modeling, or tell stories with Domain Storytelling? And even the words differ: is it an event or a domain event, a command or an intent, a read model or a projection? Each camp has its own vocabulary, its own preferred tools, and its own conventions, and each is internally coherent and externally hard to reconcile with the others.

The fragmentation reaches further than methodology. It runs all the way down to the examples we teach with. For example, WPS reaches for a cinema box office to explain Domain Storytelling. Bastian Waidelich and Sara Pellegrini, in contrast, use a student enrolling in courses. We at the native web, for our part, usually tell the story of a city library. Three teachers, three canonical "hello world" examples, and a newcomer left to work out, entirely on their own, that all of these are really describing the same handful of underlying ideas .

It shows up in tooling, too. One team builds on Axon, another on a framework it built in-house and never published; we build on EventSourcingDB, with OpenCQRS and Nimbus . Each choice is reasonable on its own island, and each comes with assumptions that quietly leak into how people think the whole field works. The result is that what you learn in one camp is only ever a slice of the whole, and it takes a very long time to figure out who belongs where and how the pieces actually fit together.

That cost lands squarely on the people we...