DEV.BG DotNetworking Conference 2026 - Event Modeling

6 min read 1,151 words
Architecture , Event Modeling , Conferences

Surprise, You Are Fired!

This is a companion guide to my presentation, given at the 2026 Dev.BG DotNetworking Conference . It summarizes the talk + gives provides quick access to resources like the presentations itsels, repositories, and additional resources to get started with Event Modeling.

About the conference

On April 18, 2026, I had the pleasure of speaking at .NET Conference in Sofia — one of the largest gatherings of the .NET community in Bulgaria, bringing together software engineers, engineering managers, and company owners from across the country and the region.

My session was titled “Event Modeling: Next Evolution of Designing Software Systems” — a 45-minute talk aimed at questioning a lot of what we take for granted in how we build business applications today, and showing a practice that I believe changes the game, especially in the age of AI.

This post is the companion guide to that presentation. If you were in the room — welcome back. This is the place to revisit the ideas, look up the references I mentioned, and try things on your own. If you weren’t — you’ll still get the full arc of the talk here, just without the live demo adrenaline and the in-room reactions.

Why this talk exists

We’re an industry that, in nearly 20 years, has not changed its fundamental tools: the same databases, the same patterns, the same “best practices”. And yet — we still miss deadlines, we still ship bugs, we still drown in Jira tickets, and we still argue in code reviews about things that should have been settled long before code was written.

We’re trying to solve 2026 problems with tools designed in the 1980s and 1990s.

Event Modeling is the first practice I’ve come across that doesn’t try to add another layer on top. It does the opposite — it takes things away.

{/* IMAGE: Slide listing “the lies of our industry” — DRY, Jira, microservices, sagas, TDD, CRUD, agile, etc. */}

Things you’ll have to question

Before talking about what Event Modeling is, the talk opens by listing what it forces you to un-learn. This list is intentionally provocative — feel free to disagree, but please disagree after you’ve tried Event Modeling on a real slice of work.

  • DRY — one of the most dangerous principles in the wild. It massively increases coupling and detonates around year 3.
  • Jira — the place where information goes to die. Event Modeling replaces it.
  • Microservices — they massively complicate every system, often along the wrong boundaries.
  • Trunk-based development & feature toggles — unfinished code in production, dressed up as a process.
  • Sagas — usually a monster in disguise. Most can be replaced with a TODO list.
  • Refactoring — sacred to many of us. But why touch code that already works? Done is done.
  • TDD — pushes design to happen on the fly, away from the business.
  • CRUD — the industry default. The question is what should replace it.
  • Hourly billing — if we’re engineers, why can’t we work with a fixed price? With Event Modeling, you can.
  • Normal forms — the aversion to data duplication ties our hands. Duplicating data is wonderful.
  • Code reviews — most of their value disappears when design happens before code.
  • Aggregates — even DDD veterans get them wrong. DCB (Dynamic Consistency Boundary) lets us drop them altogether in many cases.
  • Agile — killed years ago by certifications. There’s good in it, but its current form actively pushes design too late.

Are we the only engineering profession that can’t meet deadlines and where something is always unclear?

What Event Modeling promises instead

{/* IMAGE: “Promises” slide — the bullet list of promises rendered visually */}

  • Everyone speaks one language. The model is the shared artifact between business, design, and engineering.
  • No unclear requirements. The whole team agrees long before code is written.
  • No merge conflicts. Slices are independent — conflict probability approaches zero.
  • No changing existing code. Once a feature is built, you don’t go back. Add slices, don’t edit them.
  • No soup of patterns. Not 50 patterns. Four. Every system, large or small, is built from the same four building blocks.
  • No Jira. The model is the backlog.
  • Fast onboarding. New colleagues are productive on day one or two.
  • Predictable deadlines. Slices are estimable. Projects become quotable, not gambleable.
  • Full audit trail. The history of the system is the system.
  • Applicable in any project — from a $1k side-project to a $10M platform.
  • Better results with AI. A simple practice with a precise spec is exactly what LLMs need.

What is Event Modeling?

Event Modeling is a method for describing information systems through examples of how the information in them changes over time.

That’s the non-technical version. The technical version: it’s a visual, slice-based way to design systems where the source of truth is events — immutable facts about what has happened — and everything else (state, views, automations) is derived from them.

{/* IMAGE: A full event model (zoomed out) — the warehouse demo board, showing swimlanes and slices */}

Feel free to watch the whole talk on Youtube. The video is only available in Bulgarian - Event Modeling: Next Evolution of Designing Software Systems | Милан Нанков

References

Event Modeling

Event Sourcing

Complexity & Industry Critique

Presentation Craft

  • The Storyteller’s Spellbook — James A. Whittaker (book) — for anyone who wants their next talk to land

Resources to get started

A few lines to remember

Don’t add stuff. Throw stuff away. — Adam Dymitruk

It’s powerful because it’s simple. — Vaughn Vernon

Four patterns. Every system. No exceptions.

State is one frame. Events are the whole movie.

Stop describing what the system is. Describe what happens in it.

If your business can’t read your specification, it isn’t worth anything. With Event Modeling — they can.

Now go remove something from your stack.

— Milan

Share:

Comments