Adam Dymitruk hat Event Modeling erfunden. Er ist Gründer und CEO der AdapTech Group.

Golo Roden: Adam, Du hast Event Modeling entwickelt und unterrichtest und verfeinerst diesen Ansatz nun seit Jahren. Du bist außerdem Gründer der AdapTech Group und hast mit unzähligen Teams an der Einführung dieses Ansatzes gearbeitet. Bevor wir in die Methode selbst einsteigen: Kannst Du kurz erzählen, welches Problem Du ursprünglich lösen wolltest? Gab es eine konkrete Frustration mit bestehenden Ansätzen, die Dich dazu gebracht hat, etwas Neues zu entwickeln?

Adam Dymitruk: Im Kern ging es um eine Sache, die Design-Lücke. In nahezu jeder anderen Ingenieursdisziplin, egal ob du eine Brücke oder ein Haus baust, hast du einen Bauplan. Du hast eine visuelle Darstellung, an der jeder erkennen kann, was genau gebaut wird. In der Software hingegen versuchen wir seit Jahrzehnten, komplexe Systeme mit nichts als Ticket-Stapeln zu bauen. Und schlimmer noch: mit unterschiedlichen Tickets für unterschiedliche Rollen.

Ich habe überall die gleichen Fehlermuster gesehen. Agile brachte uns einen Backlog aus zusammenhanglosen Aufgaben, aber keine kohärente Vorstellung davon, wie Informationen tatsächlich über die Zeit durch das System fließen. Das aufwendige Design von RUP (Rational Unified Process) und UML (Unified Modeling Language) haben wir gegen gar kein Design eingetauscht. Gleichzeitig hat sich unsere Branche immer wieder in Abstraktionen verliebt, die naturgemäß subjektiv sind und sofort zum Kompromiss werden, sobald mehrere Menschen sie teilen müssen. Spezifikationen für traditionelle Systeme ignorierten die Vorteile einer minimalen, sinnvollen Kopplung über einen unveränderlichen Ledger aus Events, und traditionelle Datenbanken sind auf den Status Quo ausgelegt: sie zeigen dir, was da ist, aber niemals, wie es dorthin gekommen ist. Dieser Mangel an Kausalität macht es deutlich schwieriger, das System zu auditieren, zu skalieren oder zu erklären. Obendrein gab es die weitverbreitete Unfähigkeit, Aufwände in der Softwareentwicklung zu schätzen, und ich wusste, dass ich unseren Kunden verlässlichere Budgets und Zusagen machen konnte.

Mir wurde letztlich klar: Wenn wir das System als Storyboard darstellen könnten (wie ein Filmskript oder einen Screencast dessen, was kommen soll), könnten wir die Lücke zwischen Business und Technik mit einer universellen und menschenfreundlichen Notation schließen.

Das klingt nach einer faszinierenden Herausforderung. Mittlerweile hat Event Modeling erhebliche Verbreitung in der Event-Sourcing- und DDD-Community gefunden. Als Du es zum ersten Mal vorgestellt hast: Hast Du erwartet, dass es so breit Anklang findet, oder war es zunächst etwas, das Du für Deine eigenen Teams gebaut hast?

Dymitruk: Es war eher eine Art Geheimwaffe für uns bei AdapTech, bevor die globale Community darauf aufmerksam wurde. Ich hatte ursprünglich nicht vor, einen neuen Industriestandard zu schaffen. Ich wollte einfach nur Projekte, die kein Geld verbrennen, und Entwickler, die nicht an Scope Creep und unvorhergesehener Komplexität ausbrennen.

Breite Resonanz fand das Ganze, als ich 2018 den ursprünglichen Artikel veröffentlichte, um es von anderen Ansätzen abzugrenzen, denn ich nutzte die Notation, um Event Sourcing und andere Konzepte in verschiedenen Tech-Communities zu erklären. Auf Hacker News wurde er an diesem Tag zur Top-Story hochgevotet.

Wie sich zeigt, sind alle, unabhängig vom Tech-Stack, das Stille-Post-Spiel mit Anforderungen leid. Die Leute wollen das Gesamtbild sehen. Sie wollen das Filmskript ihres Systems sehen, bevor sie Millionen für die Verfilmung ausgeben.

Event Modeling auf den Punkt gebracht

Das ist ein ziemlich breites Publikum. Angenommen, jemand liest dies, der den Namen schon einmal gehört, Event Modeling aber noch nie ausprobiert hat. Wenn Du die Kernidee in zwei Minuten erklären müsstest, was würdest Du sagen?

Dymitruk: Wenn ich nur zwei Minuten habe, lasse ich den Tech-Speak weg und komme direkt zum Punkt: Event Modeling ist das Filmskript-Storyboard für dein System. Die meisten Softwareprojekte scheitern, weil jeder auf ein anderes Puzzleteil schaut. Entwickler schauen auf Code, Manager auf Jira-Tickets, und der CEO auf eine Präsentation. Event Modeling holt alle in einen Raum, wo sie gemeinsam auf denselben Blueprint schauen: einen, der anhand konkreter Beispiele zeigt, wie sich Information über die Zeit durch das System bewegt.

Stell dir dein System als Zeitleiste vor. Von links nach rechts bilden wir genau ab, was Schritt für Schritt passiert. Wir verwenden vier einfache Bausteine, mehr nicht:

1. Der Screen (UI): Was sieht der Nutzer tatsächlich? Noch keine High-Fidelity-Designs, gerade genug, um die Information zu zeigen.
2. Das Command (Blau): Die Absicht des Nutzers. „Ich möchte diesen Raum buchen.“ Das ist der Auslöser für eine Veränderung.
3. Das Event (Orange): Die unveränderliche Tatsache. „Raum gebucht.“ Das ist die Geschichte deines Systems. Sobald es passiert ist, ändert es sich nie mehr.
4. Die State View (Grün): Die Information, die der Nutzer sehen muss, um die nächste Entscheidung zu treffen oder um sich bestätigen zu lassen, dass das System getan hat, was er wollte.

Statt über User Stories zu streiten (die oft nur vage Wünsche sind), zeichnen wir die gesamte Reise als Storyboard. Wenn du den Fluss von einem Screen zu einem Command, zu einem Event und dann zurück zu einer View auf einem anderen Screen nicht zeichnen kannst, dann hast du keine Anforderung. Du hast eine Vermutung. Am Ende einer Session hast du keinen Stapel Tickets, du hast einen Blueprint. Er ist so klar, dass ein Entwickler genau weiß, was er bauen muss, und der Business-Owner genau weiß, wofür er bezahlt. Wir holen Software vom kreativen Schreiben zurück zum Engineering.

Mir gefällt das Bild eines Blueprints im Vergleich zu einem Stapel Tickets, weil es die ganze Idee viel greifbarer macht. Diese visuelle Zeitleiste, die Commands, Events und Views verbindet, war für mich immer das herausragende Merkmal von Event Modeling. Was macht dieses Format so wirkungsvoll, im Vergleich etwa zu einer Liste von User Stories oder einem klassischen Anforderungsdokument?

Dymitruk: Kontext. Mit einer Liste von User Stories schaust du auf einen Stapel Tickets. Es ist, als würde man dir 500 zufällige Frames aus einem Film geben und Dich bitten, die Geschichte zu erzählen. Du verstehst vielleicht, was in Frame 42 passiert, aber du hast keine Ahnung, wie wir dorthin gekommen sind oder wohin es als Nächstes geht.

Der Blueprint krempelt alles um, weil er dem einen Ding Rechnung trägt, dem Software nicht entkommen kann: der Zeit.

Er beendet das Stille-Post-Spiel, das man von traditionellen Anforderungen kennt. Ein Business-Analyst schreibt eine So-sollte-es-sein-Anforderung, ein Entwickler übersetzt das in ein Klassendiagramm, und ein Tester versucht zu erraten, was ursprünglich gemeint war. Mit dem Blueprint haben wir eine gemeinsame Sprache. Wir alle schauen auf dieselbe Zeitleiste. Wenn ein Stakeholder ein Raum-gebucht-Event sieht, aber feststellt, dass davor kein Zahlung-verarbeitet-Event steht, kann er auf die Lücke zeigen. Das geht mit einem 40-seitigen Word-Dokument oder einem Jira-Backlog nicht.

Er entlarvt auch die Magie. User Stories sind berüchtigt für ihr vages Geschwafel. In einer Story heißt es dann vielleicht: „Als Nutzer möchte ich eine personalisierte Empfehlung erhalten.“ Großartig. Wie? In einem Event Model musst du offenlegen, wie es funktioniert. Wenn du die Linie von den Daten zum Screen nicht ziehen kannst, existiert das Feature nicht. Das zwingt uns, früh mit der Realität umzugehen, statt zwei Wochen vor dem Launch fehlende Teile zu entdecken.

Der Blueprint ist außerdem im großen Maßstab begreifbar. Du kannst Dich vor ein sechs Meter langes Event Model an der Wand stellen (oder vor ein riesiges Miro-Board) und ein komplexes Banking-System in zehn Minuten verstehen. Du folgst einfach den Pfeilen. Versuch das mal mit einem Jira-Backlog. Du klickst drei Stunden lang auf „Nächste Seite“ und weißt immer noch nicht, wie die Zinsberechnung tatsächlich den Monatsauszug beeinflusst. Der Blueprint gibt dir räumliches Gedächtnis: Du erinnerst Dich daran, dass die Checkout-Logik dort drüben rechts ist, und das macht Navigation und mentales Modellieren mühelos.

Schließlich macht er Integration sichtbar. Wir bauen die Login-Story, dann die Profil-Story. Aber bei Software geht es darum, wie diese Dinge zusammenspielen. Der Blueprint zeigt die Integrationspunkte als First-Class Citizens. Wir sehen genau, wie ein Event im Versand-Slice eine View im Kundenservice-Slice beeinflusst.

Die Sprache, die die Lücke überbrückt

Ich habe kürzlich darüber geschrieben, wie Event Sourcing eine gemeinsame Sprache zwischen technischen und nicht technischen Personen schafft. Wie verändert Event Modeling Deiner Erfahrung nach die Dynamik in einem Raum, wenn Entwickler und Domänenexperten zusammensitzen? Gibt es einen Moment, in dem Du typischerweise das Klick-Erlebnis siehst?

Dymitruk: Der Klick ist meist hörbar. Es ist dieser Moment in einem Workshop, in dem die Spannung im Raum einfach … verfliegt. Vor Event Modeling hattest du die Business-Seite auf der einen Seite des Tisches und Tech auf der anderen. Die Business-Leute sind frustriert, weil sie das Gefühl haben, ins Leere zu schreien, und die Entwickler sind frustriert, weil sie etwas bauen sollen, das noch nicht definiert wurde. Es läuft auf ein „Rate, was ich denke“ hinaus.

Der Klick passiert meist während der Storyboarding-Phase. Wir haben das chaotische Brainstorming mit den orangefarbenen Klebezetteln (Events) hinter uns und beginnen jetzt, sie auf der Zeitleiste auszurichten. Der Moment der Erkenntnis kommt, wenn ein Domänenexperte, vielleicht ein Versandleiter oder ein Buchhalter, auf den Bildschirm zeigt und sagt: „Moment, wenn das Event Bestellung versandt dort passiert, woher weiß der Kunde dann seine Tracking-Nummer? Wir haben dafür keinen Screen.“

Das ist der Klick. Zum ersten Mal ist die Business-Person nicht bloß ein Gast in einem technischen Meeting; sie ist die leitende Architektin. Sie erkennt, dass die orangefarbenen Klebezettel die Realität ihres Geschäfts sind, und dass der Blueprint das erste Mal ist, dass sie die Logik ihres eigenen Unternehmens in einer Form sehen, die für sie wirklich Sinn ergibt.

Von diesem Punkt an verschiebt sich die Dynamik grundlegend. Entwickler hören auf, „Mach dir keine Sorgen, wie das funktioniert“ zu sagen, und beginnen stattdessen: „Schauen wir mal auf die Zeitleiste.“ Das Gespräch verlagert sich von abstraktem Vertrauen zu empirischer Evidenz. Da wir alle auf dieselbe 2D-Karte von Information schauen, die sich durch die Zeit bewegt, gibt es keinen Spielraum mehr für Interpretation. Wenn ein Schritt fehlt, ist das ein physisches Loch an der Wand. Ich habe CEOs erlebt, die seit 20 Jahren keine Zeile Code mehr gelesen haben und ganz begeistert waren, weil sie das System endlich lesen konnten. Sie merken, dass sie die Logik selbst auditieren können, ohne einen Übersetzer zu brauchen.

Wenn alle im Raum erkennen, dass Events die letzte Quelle der Wahrheit sind, hören sie auf, über Klassen und Datenbanken zu streiten, und beginnen, über die Reise zu sprechen. Das ist der Moment, in dem du aufhörst, eine Entwicklungsbude zu sein, und anfängst, ein Engineering-Team zu sein.

Das klingt beeindruckend, und ich kann mir sehr gut vorstellen, wie sich dadurch das Gespräch verändert. Nicht-technische Stakeholder wirklich am System-Design zu beteiligen, ist eines der schwierigsten Probleme unserer Branche, und was Du beschreibst, klingt sehr vielversprechend. Kannst Du uns mehr darüber erzählen, wie sich das in der Praxis darstellt? Hast Du ein Beispiel, bei dem Event Modeling Menschen ins Gespräch gebracht hat, die normalerweise außen vor bleiben?

Dymitruk: Es ist ein klassisches Problem: Wir gehen in einen Raum und fangen an, über Encapsulation, Microservices und Aggregates zu reden, und die Business-Stakeholder (die Leute, die tatsächlich wissen, wie das Geld verdient wird) schalten einfach ab. Sie haben das Gefühl, in einer Sprache belehrt zu werden, auf die sie sich nie eingelassen haben.

Event Modeling löst das Problem mit einem Vokabular aus vier Begriffen: den Screens, Commands, Events und State Views, über die wir bereits gesprochen haben. Das war’s. Wenn du einen Klebezettel, eine Zeitleiste und einen Screen verstehen kannst, bist du Architekt. Wir reden nicht mehr über Klassen, sondern über Events (Tatsachen, die geschehen sind). Wir reden nicht mehr über API-Endpunkte, sondern über Commands (was der Nutzer tun möchte). Wenn du die Einstiegshürde so weit senkst, vereinfachst du nichts unzulässig, sondern erhöhst tatsächlich die Strenge, weil die Personen mit dem meisten Wissen endlich teilnehmen können.

Ich erlebe das oft bei Buchhaltern oder Compliance-Verantwortlichen. Das sind Menschen, die in Tech-Meetings traditionell extrem gelangweilt sind. Ich erinnere mich an eine Session für ein großes Logistikunternehmen, in der wir den Erstattungsprozess modelliert haben. Die Entwickler hatten ein komplexes Diagramm mit State Machines und Status-Flags. Der CFO saß im Raum und schaute verwirrt.

Wir sind zu einem Event Model gewechselt und haben die Zeitleiste gezeichnet: Zahlung empfangen (Event), dann Erstattung angefordert (Command), dann Erstattung ausgegeben (Event). Plötzlich stand der CFO auf, zeigte auf die Lücke zwischen Anfrage und Ausgabe und sagte: „Moment. Bei uns kannst du nicht einfach eine Erstattung ausgeben. Du brauchst erst einen Audit-Log-Eintrag und ein Steuerumkehr-Event, sonst verstoßen wir gegen das Gesetz.“

Darauf waren die Entwickler nicht einmal gekommen. Weil wir uns nicht hinter technischem Jargon versteckt haben, konnte die Person, die die rechtliche Realität des Geschäfts verstand, das Loch in der Zeitleiste sehen. Das ist die Stärke des Blueprints: Er macht den Domänenexperten zum Lead-Validator.

Wir Menschen sind zum Geschichtenerzählen geboren. Wir erzählen seit 50.000 Jahren Geschichten an Lagerfeuern; wir schreiben seit etwa 30 Jahren Java. Wenn du eine Zeitleiste zeigst, knüpfst du an die Art und Weise an, wie das menschliche Gehirn Informationen natürlich speichert. Das verlagert das Gespräch von „Wie programmieren wir das?“ zu „Stimmt diese Geschichte?“.