40 Practitioners, 2 Days, and the Future of Software Design: What Happened at the First Event Modeling Conference in Munich?

Wednesday morning. I’m standing in front of a room, looking out at 40 practitioners who flew in from across Europe and from even further away to be here. Event modelers. Event sourcing experts. People who’ve been doing this work in the trenches, building real systems, facing real problems.

This wasn’t a typical conference with keynote speakers talking at passive attendees. This was something different. This was practitioners coming together to help each other solve the hardest problems in our field.

And honestly? I was super nervous.

The Bold Move

Organizing a conference is always a risk. What if people didn’t show up? What if the discussions fall flat? What if two days together didn’t deliver the value I believed it would?

But I had a conviction: nothing beats face-to-face discussions when you’re wrestling with complex modeling challenges.

I’ve been evangelizing Event Modeling for years. I’ve modeled hundreds of systems. I’ve written a book, created courses, run workshops. But this? This was about creating a space for the community to collide, debate, and discover together in a safe place.

I wanted to see what would happen when we stopped presenting at each other and started working together on real problems.

Day 1: Adam’s Keynote Sets the Tone

After my welcome, we kicked off with Adam Dymitruk . No slides. No deck. Just Adam talking.

And it was exactly what the room needed.

Adam’s keynote was inspirational - not in a motivational poster way, but in a “this is why we do this work” way. He talked about the fundamental principles of Event Modeling, where it came from, the philosophy behind it, and why it matters. He reminded everyone in that room why they’d invested years learning this approach.

Watching Adam deliver that keynote, I felt a wave of relief. We’d set the right tone. The next two days were going to work.

Some announcements were also made during the Keynote.. talking about the planned Certification program for Event Modeling and also a Joint-Venture between Adam and me.. a new company that will focus on Tooling and Standardization for Event Modeling - driving forward the “engineering” part of Event Modeling.

The Unusual Experiment: 5 Rooms of Practitioners

Then we did something unusual.

Normally, when you run an Event Modeling workshop, you have one expert facilitating and everyone else learning and contributing.

Not this time.

We split into five teams, each working on a different problem. But every room was packed with practitioners. People who’d been doing Event Modeling for years. People who had strong opinions, battle-tested patterns, and real-world scars.

I didn’t know what would happen.

Would they collaborate smoothly? Would it turn into debates about “the right way” to model things? Would egos clash?

I popped my head into different rooms throughout the session, and what I saw was fascinating.

People were discussing different approaches. Challenging each other’s assumptions. Asking “what about this edge case?” and “how would you handle this scenario?” The energy was intense - not combative, but deeply engaged. For some… too chaotic.. but that´s what the early phases have to be.

This was pattern recognition happening at high speed. When practitioners challenge each other respectfully, learning accelerates exponentially. You can’t get this from a course or a book. The collective intelligence of that room was remarkable.

The Marketplace: Letting the Community Drive

After lunch, we ran a marketplace session. Anyone could pitch a topic in two minutes. Then we dot-voted on what to discuss in the afternoon.

I’ll be honest - letting go of control was uncomfortable. What if nobody pitches? I had ideas about what we should cover. But I trusted the community to know what they needed.

And of course, one topic rose to the top immediately: DCB (Dynamic Consistency Boundary) vs. Aggregates.

The most prominent debate in the event sourcing world right now.

The Big Debate: Are Aggregates Really That Bad?

We had Allard Buijze from AxonIQ and Adam Dymitruk in the room. We had practitioners who’d been doing DCB for years. We had others defending aggregates, saying “they work fine for us.” And we had newcomers trying to understand what all the fuss was about.

This isn’t just an academic debate. These are real architecture decisions with real consequences. Teams have invested years building systems on aggregate-based patterns. Is DCB solving a problem most teams don’t actually have? Or is it the inevitable future?

The discussion was rich. People shared war stories - systems that scaled beautifully with aggregates, and systems that collapsed under their weight. Teams that tried DCB and never looked back, and teams that simply couldn´t figure out yet, if it was a thing at all..

I listened more than I spoke. Because here’s the thing: after modeling hundreds of systems, I’ve learned that the answer is almost always “it depends.”

Do you keep it everything as it is with aggregates and risk hitting the typical issues later? Or do you invest in DCB upfront? It depends..

What I love about this community is that we can have these debates without it turning personal. We’re all trying to build better systems. We just have different experiences informing our choices.

Day 1 Close: OpenCQRS 1.0

We closed the first day with Frank Scheffler introducing the 1.0 release of OpenCQRS - a lightweight Java-based framework for building event-sourced systems.

This was a milestone. OpenCQRS is production-ready. It’s another tool in the toolbelt, another sign that the ecosystem is maturing.

The frameworks are the tools, but we still need practicioners using them. The point is the community. The point is practitioners helping each other solve real problems. The frameworks are enablers.

And not to forget… the amazing Dinner together as a Closing Ceremony of the first day.

Day 2: The Future Arrives

I opened Day 2 with a few words, and then handed it over to Allard Buijze for the keynote.

And what Allard showed us… it was the future arriving in real time.

The new AxonIQ platform. AI-powered code generation. Event Models turning into working code, automatically.

I’m not exaggerating when I say: this is exactly what I predicted.

In January 2024, I gave a webinar. The recording is still available. And I said, on record, publicly: “Our industry will change completely within two years.”

People thought I was being dramatic. But I wasn’t.

Because here’s what I saw coming: we’re moving away from writing code and towards designing systems. AI will handle the rest. And we are within the predicted 2 year timeframe - and it´s happening right now.

Event Modeling is the key that unlocks this transformation. If you don´t use it, you´ll be left behind.

Why I Was So Certain

Event Models are structured. They’re precise. They’re complete. They define the events, the commands, the read models, the flows. Everything you need to build a system is in the model.

Of course AI would eventually be able to turn that into code. It’s not a wild prediction - it’s just logical.

For years, we’ve had the design (the Event Model) and then we’ve had to manually translate it into code. That’s always felt like redundant work. Why model the system and then code the system? Why not model the system and generate the code?

And now, watching Allard’s keynote, I was seeing it happen. Real tools. Real code generation. Real AI understanding Event Models and producing working software.

It was the realization that this is moving even faster than even I expected.

What does this mean for developers? What does this mean for my clients? What does this mean for my company? Guess what, I practice what I preach - this is reality for me since I started working with Event Modeling.. Code generation, System Design, AI - you can have that all today.

But one thing is clear: the teams that learn Event Modeling now are positioning themselves for this shift. The teams that don’t… they´ll have trouble to keep up.

Live Event Modeling with 40 Practitioners

After Allard’s keynote, we did something ambitious: live Event Modeling with the entire conference.

Forty practitioners. One problem. Modeling together.

Facilitating this was… intense.

You have forty people with strong opinions, different experiences, different patterns they’ve internalized. How do you keep it moving forward without shutting down good conversations? How do you allow space for discovery without letting it turn into analysis paralysis?

I focused on keeping us anchored to the problem. When discussions started getting too theoretical, I tried to pull us back to the specific scenario. When someone raised a good question, I made sure we explored it, but with a time box. Not that easy..

And once again, the question that kept surfacing was: “How do I model automations? Where does the logic go?”

This question isn’t going away. And the collective wisdom of the room - people sharing how they’ve solved it, debating trade-offs, challenging each other’s assumptions - that’s where real clarity emerges.

The Breakthrough: Where Do You Put the Logic?

Someone from the community presented a real-world use case. They were building a system with complex automation rules - decisions that needed to happen automatically based on incoming events. The question was: do you model that logic as part of your domain, or do you treat it as a separate automation layer?

The room dove in. Different people had different approaches. Some said, “It’s business logic, it belongs in the domain.” Others said, “No, it’s orchestration, keep it separate.”

And then I said something that I think caused a visible shift in the room:

“Just because the event is in the Event Model doesn’t mean it has to be in the code later.”

You could see it on people’s faces. A collective “wait… what?” moment.

Because here’s what most people assume: the model IS the implementation. If it’s on the board, it goes in the code exactly like that. One-to-one mapping.

But that’s not how it works.

The Model Is Not the Implementation

The Event Model is a design tool. It’s a communication tool. It helps you align stakeholders, understand the domain, and visualize how the system should behave.

But when you move to implementation, you make pragmatic engineering decisions.

Maybe that event in your model doesn’t need to be persisted. Maybe it’s just a step in a workflow that can be handled internally. Maybe you combine three events into one for performance reasons. Maybe you split one event into two because of team boundaries.

The model gives you clarity and alignment. The code gives you working software. They’re related, but they’re not the same thing.

I didn’t learn this from a book. I learned it from modeling hundreds of systems and seeing what actually works versus what looks good on paper.

Over time, I learned to use the model as a guide, not a blueprint.

And when I said that out loud at the conference, I could see people’s mental models shifting. They were realizing: I have more freedom than I thought. The model doesn’t lock me in. It gives me clarity so I can make better implementation decisions.

That realization unlocks so much. Teams get stuck trying to force their code to match the model perfectly. But that creates rigidity. The freedom to diverge from the model in code - when it makes sense - leads to better, more maintainable systems.

Another insight: The Zoom-In Approach

The other major discussion around automations was about modeling depth.

Here’s the problem: if you have a complex algorithm or detailed automation logic, do you put all of that in the Event Model? If you do, the model becomes cluttered. You lose the high-level view. But if you don’t, where do you capture those details?

I shared an approach I’ve been using: the two-model approach.

Keep the main Event Model high-level. Focus on the information flow. When you have a complex slice - an automation, an algorithm, a detailed workflow - create a second “zoom-in” model. It’s like zooming in on one part of the system to see the details, while the main model stays clean and readable.

This resonated immediately. People had been struggling with this exact problem. Now they had a practical pattern they could apply.

It’s one of those things that seems obvious in hindsight, but only after you’ve hit the problem a few times. I discovered this approach out of necessity - there was a project where I tried cramming every detail into one model, and it became a mess. Unreadable. Hard to discuss. So I started separating the levels of detail, and it worked.

That’s the beauty of getting practitioners in a room together. Someone shares a pattern that took them months to figure out, and everyone else can adopt it immediately.

The Closing: Cratis and the .NET Ecosystem

We closed the conference with a talk about Cratis by Einar Ingebrigtsen , a .NET-based CQRS platform.

The session was chosen by the community in the marketplace session. People wanted to see what’s happening in the .NET world.

And it’s a good sign. OpenCQRS for Java. Cratis for .NET. AxonIQ evolving rapidly. The tools are maturing across ecosystems.

Tooling, People, Processes…

Pattern Recognition Over Hundreds of Systems

Here’s something I haven’t talked about much publicly: I didn’t learn Event Modeling from a dramatic “aha moment.”

I learned it from repetition.

I’ve modeled hundreds of systems. And over time, patterns emerged. I started seeing what works versus what looks good on paper. I started understanding the gap between model and implementation. I started recognizing when to use certain patterns and when to avoid them.

No single project taught me everything. It was the accumulation. The slow build of pattern recognition.

But here’s what I realized at this conference: that learning accelerates exponentially when you’re in a room full of other practitioners.

You can compress years of learning into two days when you’re having the right conversations with the right people.

Someone shares a pattern they discovered after six months of painful trial and error. Now everyone in the room has that pattern. Someone asks “what about this edge case?” and three people immediately share how they handled it.

This is why face-to-face matters.

You’re Not Alone With Your Problem

The core insight from this conference - the thing I want everyone to understand - is this:

Whatever question you have, someone in that room has already solved it.

Event Modeling and event sourcing are still relatively niche. Most teams are isolated, figuring it out on their own. They hit a problem, they struggle, they experiment, and eventually they find a solution. But it’s lonely. It’s slow.

This conference showed: there’s a community, and they have answers.

Struggling with where to put automation logic? Multiple people have wrestled with this and found patterns that work.

Trying to figure out how to handle modeling depth? There are approaches you can adopt immediately.

Debating DCB vs. aggregates? There are practitioners with years of experience on both sides who can share their war stories.

You don’t have to figure this out alone.

What Happens Face-to-Face That You Can’t Get Anywhere Else

I’ve built an online course. I’ve written a book. I run workshops. All of these are valuable.

But face-to-face discussions spark something different.

It’s the speed of feedback. Someone asks a question, and the answer comes immediately - not just from me, but from five other people in the room with different perspectives.

It’s the body language. You can see when someone’s confused. You can see when an insight lands. You can see when a debate is productive versus when it’s getting stuck.

It’s the spontaneous tangents. Someone asks “what about this edge case?” and suddenly you’re down a rabbit hole that leads to a breakthrough nobody expected.

It’s the energy of collective problem-solving. Forty brains working together on a hard problem. That’s different from one person teaching and everyone else listening.

I’m thinking about how to create more of these spaces. More in-person workshops. More community gatherings. Because the value is undeniable.

After the Conference Is Before the Conference

We’re doing this again.

Why?

Because the value was undeniable. Because the community needs this. Because the conversations we had in those two days can’t be replicated anywhere else.

What will the next conference look like? I’m not sure yet. One thing is certain - it will be much bigger. Maybe a different format. Maybe more structured sessions, or maybe more open space.

But one thing I know: we’re going to keep bringing practitioners together to solve hard problems

The Invitation

If you’re a practitioner struggling with Event Modeling or event sourcing, this is for you.

If you’re part of a team trying to adopt these approaches and hitting walls, this is for you.

If you’re tired of figuring it out alone, this is for you.

This isn’t about slides or theory. This is practitioners in the trenches, helping each other.

If you have questions, this is where you find answers.

The Future Is Already Here

Let me bring this full circle.

In January 2024, I said: “Our industry will change completely within two years.”

In October 2025, at this conference, I watched it happen in real time.

AI + Event Modeling = the future of software design.

We’re moving from writing code to designing systems. From implementation to intention. From manually translating models into software to letting AI handle that work.

And Event Modeling is the key that unlocks this transformation.

I’m not just teaching Event Modeling anymore. I’m helping teams prepare for this shift.

The conference proved: the community is ready. The tools are maturing. The conversations are deepening.

And nothing - absolutely nothing—beats getting in a room together to figure it out.

What’s Next?

The conference is over, but the work continues.

If you’re ready to master Event Modeling and confidently lead your team through this shift, I’m running my Event Modeling Mastery Workshop at the end of this month.

This is a 2-day workshop where you’ll learn the patterns, practice Event Modeling, get the tools, and walk away ready to apply it.

Only a few seats left.

If you want to stop struggling alone and start building systems with clarity and confidence, this is your chance.

The future of software design is here. Let’s build it together.

This will be offered only once at this price ( and you´ll get the 4+ hours Online Course, a Life-Time Event Modeling Tooling License for one Board and the “Understanding Eventsourcing” Book on top )

Event Modeling is not a “nice to have”, it´s your AI Enabler. If you don´t adopt it, you´ll be left befind. That´s my prediction for the next 12 months. It´ll be hard to catch up if you miss this train.

Need help getting started? Let´s talk. I´m specialized in driving this adoption for Teams and Corporates.

See you next year!

Martin Dilger