Angewandte Modularität - Teil 4

Der HOO-Service als Beispieldomäne

In diesem vierten Blog zur Serie „Angewandte Modularität“ geht es lediglich darum eine Fachdomäne vorzustellen, die in den folgenden Blogs benutzt wird, um verschiedene Arten von Modularität in Form von konkreten Implementierungen vorzustellen.

Stellen wir uns eine Astrologin vor, die plant mittels eines Online-Services ihre Horoskope zu verkaufen. Das Softwaresystem, das zu diesem Zweck entwickelt werden soll, heißt HOO (für HOroscope Online). Die grundsätzliche Idee ist, dass der Geschäftsprozess aus zwei Schritten besteht. In einem ersten Schritt beantragt ein Auftraggeber ein Horoskop mit einem bestimmten Typ (z.B. Beruf oder Liebe) für eine Zielperson. Zu diesem Zweck muss der Auftraggeber Daten zu sich selbst angeben, damit die Rechnungsstellung erfolgen kann. Zum anderen muss der Auftraggeber auch Daten zur Zielperson angeben, damit das Horoskop erstellt werden kann. Nach dem ersten Schritt, der Horoskop-Beauftragung, erfolgt der zweite, der Abruf des generierten Horoskops.

Die Astrologin setzt sich als Fachexperte mit einem Anforderungsanalysten zusammen. Gemeinsam erarbeiten sie folgenden Geschäftsprozess. Beim Bearbeiten einer Horoskop-Beauftragung wird (sofern alle nötigen Daten vorhanden sind) ein Horoskop und eine Rechnungsstellung erzeugt. Bei der Erzeugung des Horoskops wird ein Rechnungsfaktor ermittelt, der einen Zuschlag oder Nachlass für bestimmte Umstände darstellt (z.B. geringerer Preis für junge Leute). Während der Erzeugung der Rechnungsstellung wird der Rechnungsfaktor mit einem Basispreis verrechnet, der abhängig ist vom Typ des Horoskops. Als synchrone Antwort auf die Horoskop-Beauftragung (d.h. auf den Auftrag) erhält der Auftraggeber eine Auftragsnummer und eine Rechnung, die darüber Auskunft gibt, wie und wie viel zu zahlen ist. Wenn die Rechnung tatsächlich beglichen ist und ein Systemadministrator den Status des Horoskop-Auftrags auf Paid gesetzt hat, kann der Auftraggeber das Horoskop unter Angabe der Auftragsnummer abrufen. Nur wenn der Status Paid ist, wird das Horoskop dem Auftraggeber in der synchronen Antwort auf einen Horoskop-Abruf übermittelt.

Es soll aber noch einen schnelleren Weg geben, ein Horoskop zu bekommen. Ein Auftraggeber kann im System den Status PrePaid haben (wie das bewerkstelligt wird, bleibt zunächst offen). Wird ein Horoskop für einen solchen Auftraggeber erzeugt, wird der Status des Horoskop-Auftrags automatisch auf Paid gesetzt und der Auftraggeber kann im direkten Anschluss an den Auftrag das Horoskop abrufen.

Folgende Abbildung zeigt eine Übersicht über die Use-Cases des HOO-Services.

Diese Abbildung macht deutlich, dass der Systemadministrator nicht nur den Status eines Auftrags ändern, sondern auch eine Übersicht aller vorhandenen Aufträge im System sich anzeigen lassen kann. Für alle vier Aktionen, die im Use-Case-Diagramm oben beschrieben sind, kann ein Request an den HOO-Service geschickt werden, der mit einer Response beantwortet wird. Manche dieser Request- und Response-Objekte müssen bestimmte Datenfelder beinhalten.

Folgende Abbildung zeigt eine Übersicht dieser Objekte, die für einen Prototypen spezifiziert wurden:

Zu beachten ist, dass ein PaymentRequest keine Response zurückgibt, und auch, dass eín ListOrder-Request für den Prototypen kein Attribut braucht und als Antwort einen einfachen String-Wert zurückliefert.

Astrologin und Anforderungsanalyst unterteilen die HOO-Fachdomäne in drei Bereiche (Subdomänen): die Auftragsverwaltung kurz Order, die Verwaltung der Rechnungsstellungen kurz Invoice und Horoskop-Verwaltung kurz Horoscope. In jeder Domäne gibt es ein Domänenobjekt oder (in DDD-Terminologie) eine Entität mit bestimmten Attributen. Ein Attribut haben alle Entitäten gemeinsam: die Auftragsnummer. Diese gilt als systemweite ID an der sich zusammengehörende Aufträge, Horoskope und Rechnungsstellungen erkennen lassen.

Folgende Abbildung zeigt eine Übersicht über die drei beschriebenen Domänenobjekt.

Ein Java-Entwickler wird beauftragt, einen Prototypen zu entwickeln, um sicherzustellen, dass das beschriebene Systemverhalten praktikabel funktioniert. Nicht-funktionale Anforderungen wie Autorisierung, Authentifizierung, Performance und parallele Verarbeitung werden zu diesem Zweck ignoriert.  Der Entwickler programmiert den Prototypen als klassischen Monolithen und benutzt Maven als Build-System. Das bedeutet, dass es im Workspace seiner Entwicklungsumgebung ein Maven-Projekt gibt, dass alle benötigten Java-Klassen beinhaltet. Maven baut daraus eine JAR-Datei, welche die Hauptklasse HOroscopeOnlineService.java beinhaltet. Die main-Methode dieser Klasse lässt sich von außen aufrufen, um den HOO-Service zu testen.

Die Implementierung sieht in der Entwicklungsumgebung des Entwicklers folgendermaßen aus:

Den wesentlichen Teil der Geschäftslogik hat der Entwickler in der Hauptklasse implementiert. Diese benutzt die Domänenobjekte der drei Subdomänen. Die Hauptklasse stellt eine Art Kontrollinstanz dar (in der Abbildung unten Control genannt), die den Informationsfluss zwischen den drei Subdomänen regelt. Untereinander kommunizieren die Subdomänen also nicht.

Ein UML-Sequenzdiagramm macht die Implementierung deutlich:

Implementierung näher zu betrachten, gegebenenfalls zu ändern und auszuführen, steht auf GitHub bereit (siehe https://github.com/iks-github/DemoCode/wiki/HOO-Classic-Monolith).

Im nächsten Blog werde ich die Implementierung eines pseudo-modularen Monolithen vorstellen, den ich bereits im letzten Blog in allgemeiner Form besprochen habe. Danach schließt sich in der Blog-Reihe “Angewandte Modularität” eine OSGi-Implementierung des HOO-Services an.


Jetzt teilen: