Die Geschäftsprozesse im Zentrum der Entwicklung bei dimater
Leverkusen, 17.06.2022 | Auf einem Schiff bewegen sich die Passagiere normalerweise nur auf den sogenannten Passagierdecks. Ein Rundgang durch die verborgenen Bereiche der Technik- und Maschinendecks oder ein Ausflug auf die „Brücke“ ist dabei für viele reizvoll – sei es auch Technikbegeisterung oder einfach aus Neugier darauf, was quasi hinter den Kulissen so passiert.
Diesem Beispiel folgend möchten wir Sie an dieser Stelle zu einem kleinen Rundgang hinter die „Weboberfläche“ unserer Anwendung einladen. Keine Angst – im Folgenden soll es nicht um Programmierung und Code gehen, sondern vielmehr um die Betrachtung einiger grundlegender verwendeter Konzepte. Deren Verständnis kann im Zweifel dazu beitragen, die Anwendung in ihrer Gesamtheit ein stückweit besser zu verstehen.
Im Rahmen einer Sondervertragskundenkalkulation ist die Erstellung der zugehörigen Lastprofilprognose ein wesentlicher Faktor. Zu Generierung etwa eines Gas-Standardlastprofils (SLP) werden mehrere Eingabeparameter benötigt. Gas-SLP sind je nach Typ mehr oder weniger temperaturabhängig und benötigten zur Bestimmung der Gas-Tagesallokationsmengen eine entsprechende Auflistung von Tagesmitteltemperaturen als Eingabeparameter – als Endanwender wählen wir hierzu nur eine Temperatur-Messstelle aus, welche je nach Konfiguration auch über eine hinterlegte Zuordnung über die angegebene PLZ automatisch gewählt werden kann. Als weitere Parameter ist das Profil selbst über seinen Code bzw. seine Bezeichnung, der gewünschte Lieferzeitraum sowie der Kundenwert anzugeben.
Die „Gas-Standardlastprofilprognose“ mit ihren täglichen Allokationsmengen im Lieferzeitraum sowie den zugrundeliegenden Eingabeparametern ist hierbei als eine Einheit aus Daten und Geschäftslogik modelliert, die als „Aggregate“ bezeichnet wird. Erzeugt wird es, indem ein sogenanntes „Create Command“ mit den genannten Parametern an das Aggregate übergeben wird. Bei erfolgreicher „Bearbeitung“ des Command wird ein Ereignis (Event) vom Typ „Gas-Standardlastprofilprognose-erzeugt“ mit allen notwendigen Daten erzeugt und gespeichert. Die Commands, Events sowie die zugehörige Bearbeitungsroutinen sind Kernbestandteil der Aggregate und bilden gemeinsam die vorgenannte fachliche Geschäftslogik ab.
Soll bei der Prognose anschließend z.B. der Kundenwert angepasst werden, gibt es für genau diesen Zweck das spezielle Command „Kundenwert_anpassen“, welches inhaltlich im Wesentlichen den neuen Kundenwert umfasst. Um es zu bearbeiten, lädt das Aggregat zunächst alle zuvor gespeicherten Ereignisse (in diesem Fall bisher nur eines) in chronologischer Reihenfolge aus dem Speicher, um so seinen aktuellen Objekt-Status wiederherzustellen. Anschließend wird das „Kundenwert_anpassen“ Command bearbeitet. In dieser speziell für dieses Command erstellten Bearbeitungsroutine wird wiederum ein Ereignis, diesmal vom Typ „Kundenwert_angepasst“ erzeugt und gespeichert.
Was sind die Vorteile dieses Ansatzes?
Durch die Speicherung aller „Änderungsereignisse“ ist ein „Audit Log“, in welchem festgehalten wird, wer wann welche Änderung vorgenommen hat, automatisch vorhanden. Das schrittweise Laden der erzeugten Ereignisse ermöglicht zudem sehr einfach eine „Rückgängig machen“ Funktion zu realisieren.
Der zentrale Punkt, der uns zu diesem Ansatz gebracht hat, war jedoch ein anderer. Bei der Modellierung der Anwendung mit Commands und Events stehen die fachlichen Prozesse der Fachdomäne selbst im Zentrum und nicht mehr die Struktur der Daten. Die Commands repräsentieren hierbei die Wünsche der Anwender ans System. Die Events die als Reaktion der Anwendung geschaffenen Fakten, die unveränderlich sind und deshalb in der Vergangenheitsform stehen. Dem im Zentrum stehenden Geschäftsprozessen wird diese Vorgehensweise als Domain-Driven Design (kurz DDD) bezeichnet.
