Beitrag erstellt am: 07.05.19
Ereignismodellierung (engl. Event Modeling), entworfen und beschrieben von Adam Dymitruk, legt den Schwerpunkt auf das
observierbare Verhalten eines Systems. Im Zentrum stehen die Ereignisse, die sich in einem Unternehmen, einer Anwendung oder jeder anderen Form von Systemen im zeitlichen Verlauf
ereignen.
Ereignismodellierung nutzt zahlreiche Konzepte aus dem Domain-driven Design und verzichtet gleichzeitig auf alles, was nichts zum unmittelbaren Verständnis der betrachteten Problemstellung beiträgt. Ein prominentes Beispiel ist der Verzicht auf Aggregate. Dies im Gegensatz zum EventStorming, das Aggregate explizit als Element der Modellbildung nutzt, was nach meiner Erfahrung gerade zu Beginn wiederholt zu Diskussionen und Verständnisfragen führt
Wer für seine Projekte bereits EventStorming nutzt, dem wird vieles vertraut vorkommen. Indem Ereignismodellierung jedoch mit deutlich weniger Elementen auskommt, gelingt der Einstieg wesentlich leichter als bei EventStorming; dies zumindest nach meinen bisherigen Erfahrungen.
Es ist das erklärte Ziel von Adam, dass jeder und jede die nötigen Grundsätze und Regeln innerhalb kurzer Zeit verstehen und gewinnbringend nutzen kann. Wer es ausprobieren möchte, findet die für den Einstieg nötigen Informationen auf der Website eventmodeling.org
Meine ersten Gehversuche stimmen mich optimistisch. So freue ich mich einmal mehr auf eine spannende Lernreise. Und wer weiss, vielleicht gehört Event Modeling schon bald zum festen Bestandteil meines Werkzeugkastens. Denn gerade für auf Event Sourcing und CQRS basierte Systeme scheint mir Event Modeling eine gute Sache. Und da ich mittlerweile praktisch keinen Nutzen mehr darin sehe, meine Systeme anders als mittels CQRS und Event Sourcing zu konzipieren und umzusetzen, könnte Adams Ansatz schon bald zu einem meiner Lieblingsmethoden werden.
Ereignismodellierung nutzt zahlreiche Konzepte aus dem Domain-driven Design und verzichtet gleichzeitig auf alles, was nichts zum unmittelbaren Verständnis der betrachteten Problemstellung beiträgt. Ein prominentes Beispiel ist der Verzicht auf Aggregate. Dies im Gegensatz zum EventStorming, das Aggregate explizit als Element der Modellbildung nutzt, was nach meiner Erfahrung gerade zu Beginn wiederholt zu Diskussionen und Verständnisfragen führt
Wer für seine Projekte bereits EventStorming nutzt, dem wird vieles vertraut vorkommen. Indem Ereignismodellierung jedoch mit deutlich weniger Elementen auskommt, gelingt der Einstieg wesentlich leichter als bei EventStorming; dies zumindest nach meinen bisherigen Erfahrungen.
Es ist das erklärte Ziel von Adam, dass jeder und jede die nötigen Grundsätze und Regeln innerhalb kurzer Zeit verstehen und gewinnbringend nutzen kann. Wer es ausprobieren möchte, findet die für den Einstieg nötigen Informationen auf der Website eventmodeling.org
Meine ersten Gehversuche stimmen mich optimistisch. So freue ich mich einmal mehr auf eine spannende Lernreise. Und wer weiss, vielleicht gehört Event Modeling schon bald zum festen Bestandteil meines Werkzeugkastens. Denn gerade für auf Event Sourcing und CQRS basierte Systeme scheint mir Event Modeling eine gute Sache. Und da ich mittlerweile praktisch keinen Nutzen mehr darin sehe, meine Systeme anders als mittels CQRS und Event Sourcing zu konzipieren und umzusetzen, könnte Adams Ansatz schon bald zu einem meiner Lieblingsmethoden werden.