Wochenrückblick KW 17

Zeitmangel führt zu weniger Sport

Der Ostermontag-Reisetag und meine Fortbildung sind meine Ausrede für weniger Laufen. Wobei ich am Wochenende früher aufstehen könnte (so gegen 5 Uhr), um vor der Fortbildung zu laufen. Dafür fehlt mir die Disziplin …

Gleichzeitig breche ich meine Push-up-Challenge wieder ab. Meine rechte Schulter schmerzt wohl nicht wegen zu viel Tischtennis, denn das habe ich derzeit komplett weggelassen, in der Hoffnung, die Schulter wird besser.

• Montag Osterreisetag.
• Dienstag 15 km laufen + 1,5h im Gym.
• Mittwoch 11 km laufen, weil Knieprobleme vom Vortag.
• Donnerstag 15 km laufen + 1,5h Gym.
• Freitag Ruhetag.
• Samstag ganztägige Fortbildung.
• Sonntag ganztägige Fortbildung.

Wenn du möchtest, folge mir auf Strava

Späte Erkenntnis beim Event Sourcing

In meinem Projekt für die Entwicklung einer Therapiedokumentation nutze ich für die Persistenz das Konzept von Event Sourcing (ich habe vor ein paar Wochen in einem Artikel darüber berichtet). Im Rahmen dieses Ansatzes erstelle ich mir für die Verwaltungswebseite ein Datenmodell, das für die Zugriffe der Verwaltung optimiert ist – ein sogenanntes Read-Model. Das Datenmodell verknüpft die Entitäten Therapeut, Patient, Rezept und Dokumentation, sodass die Mitarbeitenden in den Listen beliebig sortieren, filtern und navigieren können.

Bisher habe ich für die Befüllung des Read-Models für jede Entität auf die dazugehörigen Events gelauscht und das Modell geschrieben – für Therapeuten auf die Therapeuten-Events, für Patienten auf die Patienten-Events. Für das Erstellen, Aktualisieren und Löschen der einzelnen Entitäten funktionierte der Ansatz hervorragend. Mit dem weiteren Verlauf kamen Events, die sich auf mehrere Entitäten auswirken – z. B. ein Rezept, das nachträglich verändert wird, sodass es einem anderen Patienten zugeordnet wird, oder eine Dokumentation, die anfangs ohne Rezept erstellt wird und sobald das Rezept eingespeist wurde, mit diesem verknüpft wird.

Ich habe also je Entität einen Prozess, der auf die dazugehörigen Events lauscht. Ich habe allerdings nicht unter Kontrolle, welcher Prozess die Events zuerst erhält. Wegen der oben angesprochenen Verknüpfungen zwischen den Entitäten lauschen nun mehrere Prozesse auf die gleichen Events. Es macht einen Unterschied, ob ich die Rezeptänderung erst für das Rezept speichere und danach den Patienten anhand dieser neuen Daten aktualisiere oder andersherum. Mangels meiner Kontrolle über die Reihenfolge können sich zukünftig Fehler einschleichen, die schwer zu identifizieren sind. Dies ist ein klassisches Nebenläufigkeitsproblem.

Als Lösung habe ich ein umfangreiches Refactoring gestartet. Es gibt einen einzigen Prozess für alle Entitäten, der auf alle Events lauscht und in dem die Reihenfolge gesichert ist. Ich kann die notwendigen Änderungen an den jeweiligen Entitäten vornehmen und bin die Nebenläufigkeit los.

Die späte Erkenntnis, die sich im Nachhinein betrachtet an einigen Stellen bereits angekündigt hat – nur ich habe die Zeichen übersehen – ist folgende: Für die Erstellung eines Read-Models sind alle Events zusammen in einem Prozess zu beachten, die im Read-Model miteinander verknüpft sind. Irgendwie offensichtlich … nur musste ich dies auf die schmerzhafte Weise lernen.

Start meiner Fortbildung zum Vereinsmanager

An diesem Wochenende ging meine Fortbildung beim Hamburger Sportbund zum Vereinsmanager los. Mein Ziel ist, die Tischtennisabteilung besser zu strukturieren, für die Mitglieder attraktiv zu gestalten und mit den Teams in höhere Ligen aufzusteigen. Dies alles fußt auf guter Jugendarbeit – für die ich letztes Jahr meine C-Lizenz Trainerausbildung gemacht habe. Los geht es mit zwei Mal acht Stunden zum Thema "Kommunikation und Führung".