Der erste Versuch eines einfachen Metamodells für Event-Modeling

Nein, das ist kein Bild von Gipf-Oberfrick sondern...
Beitrag erstellt am: 08.01.20
Mittlerweile nutze ich Ereignismodellierung sowohl beruflich als auch privat für die Modellierung meiner Projekte. Über das, was ich beruflich aktuell tue, kann ich nicht offen schreiben, daher beschränke ich mich hier auf meine privaten Projekte: Vor kurzem habe ich mit Flutter ein kleines App-Experiment gestartet, um diverse Dinge auszuprobieren, u.a. auch die Idee, die Anwendung modellgetrieben zu entwickeln und den nötigen Dart-Code weitgehend zu generieren, beispielsweise mit Hilfe der Generator-Workbench von actifsource, an dessen Entstehung ich in den Jahren 2005 - 2010 massgeblich mitgewirkt habe.

Grundlage für einen solchen modellgetriebenen Ansatz ist neben einer Referenz-Implementierung als beispielhafte Lösung ein Metamodell. Es beschreibt die massgeblichen Schlüsselabstraktionen, mit deren Hilfe sich die konkrete Lösung modellieren lässt.

Die Kernelemente im Event Modeling sind rasch gezeichnet:
Event Modeling Grundelemente

Vier wesentliche Elemente

Mit CQRS unterscheiden wir zwei Arten von Schnittstellen:
  • eine Kommando-Schnittstelle für Statusänderungen
  • eine Leseschnittstelle für den Lesezugriff auf Status

Im Event-Modeling finden wir beide Konzepte wieder:

  • Kommandos liefern Ereignisse, welche als Delta beschreiben, was sich aus fachlicher Sicht ereignet hat. Ein Kommando kann scheitern, es formt damit einen transaktionalen Rahmen für Änderungen. 
  • Lesemodelle beschreiben als Sichten relevante Zustände. Sie speisen sich aus Ereignissen.

Jedes Kommando hat einen Auslöser: entweder eine über das UI angestossene Aktion, ein interner Prozess oder einen Job bzw. ein Aufruf via API (Primary Port gemäss Ports & Adapter). Lesemodelle dienen, neben Benutzereingaben und API-Argumenten, als Statuslieferanten.

Die nachstehende Grafik illustriert die wesentlichen Schlüsselabstraktionen (in Blau) und ihr Zusammenspiel:
Ein vereinfachtes Metamodell - mit noch vielen Lücken
Ein vereinfachtes Metamodell - mit noch vielen Lücken
Es fällt auf, dass das Aggregat grau eingefärbt ist. Der Grund liegt darin, dass ich mir aktuell nicht sicher bin, ob ich das Aggregat als Konsistenzrahmen überhaupt noch benötige. Unter der Voraussetzung, dass ich Kommandos als pure Funktionen umsetzten kann, die aufgrund ihrer Argumente die jeweilige  Zustandsänderung in Form von Ereignissen als Ergebnis liefern, scheinen mit Aggregate durchaus verzichtbar. Da werde ich mich mit einer kleinen Referenz-Implementierung heran tasten.

Es fehlen noch zahlreiche Details! So habe ich noch keine Kardinalitäten eingetragen und auch das Thema Kommando-Argumente und Ereignis-Daten fehlt vollständig. Als Start für eine erste Exploration und einen kleinen Spike reicht es jedoch aus.