Unterstützende Dienste

Der zweite Teil des Posts diskutiert unterstützende Dienste. Unterstützende Dienste unterstützen (wie der Name vermuten lässt) Business-Microservices. Mehr noch, sie können genutzt werden, um ein effizientes und nicht langweiliges Umfeld zu schaffen, indem man die Implementierung der gleichen Aufgabe immer wieder vermeidet. Es werden Beispiele gegeben, die als unterstützende Dienste implementiert werden können. Am Ende steht eine Empfehlung mit einem großem ABER, da es keine Antwort für alles beim Programmieren gibt.

Das letzte Mal sprach ich wie Microservices entlang des Business-Prozesses geschnitten werden können (siehe https://annegretsarchitecture.blog/2018/03/08/wie-konnen-microservices-geschnitten-werden/).

Aber es sind noch ein paar Dinge offen: Unterstützende Dienste oder auch Supportive Services. Wir alle wissen, dass wir oft gegen die gleichen Dinge zu kämpfen haben: Suche nach einem Objekt, Veröffentlichen oder sogar Reporting. Solche „Dinge“ sind nicht wirklich Business-Prozess-Schritte – wie vorher erläutert – sie unterstützen den Business-Prozess. Ein Staubsauger würde mein Wohnzimmer nicht von selbst reinigen. Aber unterstützt mich in meinem Tun. In der gleichen Art und Weise unterstützen unterstützende Dienste den Business-Prozess. Da unterstützende Dienste nicht spezifisch für ein Business-Problem sind, können sie fast überall verwendet werden. Es sind sogar unterstützende Dienste über das Internet verfügbar und müssen somit nicht selbst implementiert und betrieben werden. I denke, Dein Manager liebt diese unterstützenden Dienste.

Lass uns ein bisschen tiefer in solche Dienste gehen. Was haben wir die ganze Zeit zu implementieren?

• Suche
• Veröffentlichen
• Freigabe
• Reporting

Suche

Suche meint hier, die Suche nach einem bestimmten Business-Objekt. Die Business-Objekte in unserem Beispiel sind Gebote, Ausschreibungen und Vertragsnehmer. Sie können alle durch ein bestimmtes Attribut z.B. ihren Namen oder durch eine Volltextsuche gefunden werden. Daher macht es Sinn, die Suche separat zu implementieren. Wir implementieren einen Dienst, der die Suche sogar über verschiedene Dienste ausführen kann. Die Suche nach Geboten muss über CREATE BID Microservice, die Evaluierung und den Vergabe-Service suchen. Die Suche kann implementiert werden, indem das Such-Objekt und das Such-Ziel übergeben werden. Z.B. wenn ich weiß, dass ich nur vergebene Gebote suche, dann brauche ich nur im Ziel „Vergabe“ suchen.

Es kann passieren, dass ich über alle drei möglichen Services suchen muss. In solchen Fällen können wir den Reporting-Dienst für eine bessere Performance oder es ist ausreichend, die Ergebnisse des ersten Service zu liefern und den Rest im Hintergrund zu laden. Wie auch immer, ein Nachladen von Ergebnissen (lazy loading) sollte in jedem Fall angewendet werden.

Reporting

Neben der Suche über viele Microservices – dass nach meiner Erfahrung ohnehin selten vorkommt – brauchen wir aber oft ein Reporting über viele Business-Prozess-Schritte. Wenn ich ein Ingenieur in dem Prozess bin, dann möchte ich alle meine Ausschreibungen sehen, auch wenn sie möglicherweise schon vergeben sind. Ich benutze diesen Report als Einstiegspunkt in meine Arbeit. Das Reporting wird auf einem separaten Data-Storage (einem Data Lake) implementiert, der es erlaubt die Daten so zu organisieren, dass vordefinierte Reports an die aufrufenden Clients geliefert werden können. Das heißt, wir können Reports über Vertragsnehmer und wie sie auf Ausschreibungen reagieren, erzeugen oder aber auch eine Art von Aufgabenliste für den Vergabe-Manager.

Veröffentlichen

Veröffentlichen ist ein ziemlich offensichtlicher Punkt. Wir benötigen eine Veröffentlichung für die Ausschreibung (wenn sie vom Status „Entwurf“ zum Status „Gesendet“ übergeht) und wir benötigen es nochmals für die Gebote (wiederum von „Entwurf“ zu „Gesendet“). Für beide Varianten benötigen wir eine Art von Freigabe-Workflow, der ein anderer unterstützender Dienst ist.

Freigabe

Der Freigabe-Workflow kann für die Ausschreibung, die Gebote und die Vergabe (und vielleicht auch für ein paar dazwischen liegende Status) definiert warden. Wir können den Freigabe-Workflow unabhängig vom freizugebenden Business-Objekt definieren, aber wir müssen den Statusübergang für das Business-Objekt definieren. Daher bekommt der Service eine Referenz des Business-Objekts, den Freigeber (der wohlmöglich über eine automatische Suche gefunden wurde) und einen Übergang (Entwurf zu Gesendet) der freigegeben werden muss. Mehr ist nicht notwendig und wir können jede Menge wiederverwenden.

Zusammenfassung

Dies sind nur einige Beispiele für unterstützende Dienste und wie sie verwendet werden können. Ein anderes Beispiel kann ein Signatur-Service für einen Vertrag sein, der sogar außerhalb des eigenen Unternehmens und dessen Dienste liegt. Die unterstützenden Dienste erlauben, Doppelimplementierungen zu vermeiden und Synergien zu nutzen.

ABER – natürlich ist da immer auch ein Aber in Großbuchstaben. Du erhöhst vielleicht die Abhängigkeiten zwischen Deinen Diensten, wenn Du solche unterstützenden Dienste heftig nutzt. Z.B. kannst Du gezwungen sein, jedes Mal Deinen Suchen-Dienst anzupassen, wenn das Gesamtsystem konstant wächst und jeder neue Service den Suchen-Dienst in einer spezifischen Art und Weise nutzt. Bitte schaue auf solche Fälle kritisch. Bei Fragen entscheide dich für die Implementierung im Business-Service und nicht im unterstützenden Dienst. Die Unabhängigkeit der Services und der Teams sind ein höheres Gut als irgendwas wieder zu verwenden – wenigstens nach meiner Meinung.

Am  Ende musst Du eine Balance zwischen Synergien und Unabhängigkeit finden. Die Antwort ist nicht leicht zu geben und sollte jeden Tag wieder hinterfragt werden.