Detailkonzept Anwendungskern

Fachkomponenten setzen die Anwendungskomponenten aus der fachlichen Architektur um. Sie bilden damit den Schnitt der Anwendungskomponenten in die technische Architektur ab. Fachkomponenten beinhalten möglichst wenig Technik und trennen so Anwendungslogik von Technologie.

Eine allgemeine Anwendung enthält die Fachkomponenten Erstellung, Teilnahme und Verwaltung.

Von außen betrachtet besteht jede Fachkomponente aus einer Schnittstelle (Interface) und den von ihr verwendeten Geschäftsobjekten (Model) sowie Ausnahmen (Exceptions). Alle Zugriffe auf die Fachkomponente von außen, auch von anderen Fachkomponenten aus, geschehen über die Schnittstelle.

Die Schnittstelle stellt eine Fassade (Facade) für mindestens eine Anwendungsfallklasse dar. Die Aufgaben der Schnittstelle sind:

Geschäftsobjekte dienen zur Kommunikation der Fachkomponente nach außen sowie zur Umsetzung der Fachlichkeit (z.B. für interne Berechnungen). Sie werden im Anwendungskern definiert, sind nicht persistent und können in der Nutzungsschicht wiederverwendet werden, sofern hierfür keine Anpassungen durch Mappings o.ä. nötig sind. Ein Geschäftsobjekt ist genau einer Fachkomponente zugeordnet, welche die Hoheit über es besitzt und seinen Lebenszyklus verwaltet. Sie werden primär nach ihrer Funktion benannt.

In einer allgemeinen Anwendung gibt es z.B. die Geschäftsobjekte Aufgabe, Zeitpunkt und Nutzer.

In Ausnahmefällen können Geschäftsobjekte fachlich nicht genau einer Komponente zugeordnet werden. Hierfür wird die Komponente Basisdaten definiert, die nur die eine Aufgabe hat, solche Geschäftsobjekte an zentraler Stelle zu verwalten.

Eine Anwendungsfallklasse setzt genau einen Anwendungsfall um. Ihr Schnitt ergibt sich aus der fachlichen Architektur. Anwendungsfallklassen werden anhand des Namens des Anwendungsfalls aus der Spezifikation benannt und mit dem Präfix Awf gekennzeichnet.

Eine Anwendungsfunktion setzt Teil-Abläufe um, die in mehreren Anwendungsfällen verwendet werden. Anwendungsfunktionen werden somit von Anwendungsfallklassen aufgerufen. Anwendungsfunktionen werden anhand des Namen der Anwendungsfunktion aus der Spezifikation benannt und mit dem Präfix Afu gekennzeichnet.

Die folgende Abbildung fasst den Aufbau einer Fachkomponente noch einmal grafisch zusammen.

Für querschnittliche Funktionalität innerhalb des Anwendungskerns wird das Spring-Framework genutzt. Hauptaufgabe des Frameworks ist es, die Komponenten zu konfigurieren und miteinander bekanntzumachen. Dadurch wird die Trennung zwischen Fachlichkeit und Technik verbessert. Beispiel für querschnittliche Funktionalität ist die deklarative Steuerung von Transaktionen.

Die Vorgaben zur Nutzung und Konfiguration des Spring-Frameworks werden in Kapitel Verwendung des Spring-Frameworks beschrieben.

Wenn der Anwendungskern fachliche Services benötigt, die von anderen IT-Systemen innerhalb der Plattform angeboten werden, so werden diese Services als Komponente im Anwendungskern abgebildet. Dadurch ist die Funktionalität sauber gekapselt, was die Wartbarkeit erhöht: Wenn der externe Service ausgetauscht werden soll, ist keine Änderung der gesamten Anwendung notwendig – es ist lediglich eine interne Änderung der externen Service-Komponente notwendig. Für andere fachliche Komponenten des Anwendungskerns ist nicht zu unterscheiden, ob es sich beim Aufruf einer Komponentenschnittstelle um eine in dieser Komponente implementierte Funktion oder um einen Serviceaufruf handelt. Komponenten, die externe Services kapseln, sind im Idealfall von außen nicht von fachlichen Komponenten des Anwendungskerns unterscheidbar. Neben der technischen Kommunikation erfolgt durch diese Komponenten auch die Abbildung von Schnittstellendaten und Exceptions auf die Daten der Anwendung.

Der Anwendungskern hat die Hoheit über die Geschäftsobjekte des IT-Systems. In Referenzarchitektur wurde bereits beschrieben, dass zur Strukturierung eines IT-Systems zwei Sichten verwendet werden können:

Technische Sicht: Die technische Sicht unterteilt die IT-Anwendung in Schichten für die jeweils eigene Technologien verwendet werden: Nutzung (GUI, Batch und Service), Anwendungskern und Datenzugriff. Das Ziel ist es, eine Durchmischung von Technologien zu verhindern, so darf z. B. in der GUI kein SQL formuliert werden.

Fachliche Sicht: Die fachliche Sicht beschreibt eine Teilaufgabe, z. B. Meldung, Auskunft oder Fristenkontrolle. Innerhalb dieser Teilaufgabe wird der Anwendungskern über eine GUI, Services oder Batches angesprochen, der wiederum über die Datenzugriffsschicht mit der Datenbank kommunizieren muss. Daher zerlegt die fachliche Sicht das IT-System in fachliche Säulen. Diese fachlichen Säulen werden im folgenden Teilanwendungen genannt. Das Ziel ist die fachliche Trennung und Minimierung inhaltlicher Abhängigkeiten. Die Teilanwendungen sollen Fachlichkeit kapseln.

Damit kann eine IT-Anwendung sowohl vertikal in Teilanwendungen (fachliche Sicht) und horizontal in Schichten (technische Sicht) strukturiert werden, wie die folgende Abbildung verdeutlicht.

Eine Teilanwendung erstreckt sich über alle technischen Schichten, kapselt aber die Fachlichkeit, zu der gewisse Geschäftsobjekte gehören. Um den Austausch von Objekten innerhalb einer Teilanwendung zwischen den Schichten zu vereinfachen, gleichzeitig aber unterschiedliche Teilanwendungen gegeneinander abzugrenzen, wird für die Verwendung von Objekten in Schnittstellen folgende Regel aufgestellt:

Das kann erreicht werden, indem nur Deep-Copies von Objekten an andere Teilanwendungen herausgegeben werden.

Innerhalb einer Teilanwendung dürfen über die Schichten hinweg durchaus änderbare Objekte ausgetauscht werden. Die hierfür bereitgestellte Schnittstelle der Schicht gehört damit aber zur Teilanwendung darf von einer anderen Teilanwendung nicht genutzt werden.

In einer allgemeinen Anwendung ist z.B. „Aspektanwendung“ eine Teilanwendung. Zu dieser Teilanwendung gehören in der Schicht Nutzung die Oberfläche Aspektanwendung und der Batch AspektanwendungLoeschBatch, in der Schicht Anwendungslogik die Fachkomponenten Erstellen, Verwalten und Datenpflege und in der Schicht Datenhaltung die Entitäten Aspektanwendung, Zeitpunkt, Nutzer, Intervall und Nutzerintervall.

Dies bezieht sich unter anderem auf die Bestandteile von Spring: Spring bietet verschiedene Komponenten, welche getrennt voneinander eingesetzt werden können. Es sollen nur die Komponenten eingesetzt werden, welche zu geringerer Komplexität und geringerem Entwicklungsaufwand führen.

Einheitlichkeit der Nutzung: Spring soll in den verschiedenen Anwendungen einheitlich eingesetzt werden. Hierfür sind geeignete Vorgaben für die Nutzung zu verwenden.

Verständlichkeit der Konfiguration: Die Konfiguration der Spring-Komponenten erfolgt über Annotationen an den Komponenten. Wenn erforderlich, werden Komponenten außerhalb der Anwendung über Java-Konfigurationsklassen konfiguriert.

Komponentenorientierung wahren: Über Spring sollen Komponenten konfiguriert werden: Es soll nicht möglich sein, direkt auf Implementierungsklassen einer Komponente zuzugreifen.

Das grundlegende Konzept von Spring ist das der Spring-Bean. Die Konfiguration von Spring teilt sich deshalb in zwei Teile: in die Konfiguration der Spring-Beans sowie in die Konfiguration von Spring selbst (innerhalb eines Tomcat Servers). Um die Konfiguration von Spring und der eingesetzten Bausteine einfach zu halten, werden die Autokonfigurationsmechanismen von Spring Boot eingesetzt. Diese Konfigurationsarten werden in den folgenden Kapiteln beschrieben.

Neben der Konfiguration der Beans enthält eine Anwendung kaum Abhängigkeiten von Spring: Da die benötigten Objekte per Dependency Injection konfiguriert werden, müssen diese nach ihrer Konfiguration lediglich verwendet werden.

In einigen Fällen existieren jedoch weitere Abhängigkeiten von Spring:

Für die noch nicht in anderen Konzepten besprochenen (letzten beiden) Themen werden im folgenden Vorgaben aufgestellt.

An der Schnittstelle des Anwendungskerns findet die Transaktionssteuerung statt. Jeder Aufruf wird in einer eigenen Transaktion abgearbeitet. Die Transaktion wird beim Aufruf des Anwendungskerns gestartet und mit der Rückgabe des Ergebnisses abgeschlossen (Commit) und somit beendet. Falls bei der Verarbeitung einer Anfrage ein nicht behebbarer Fehler auftritt, wird dieser an den Aufrufer zurück übermittelt. In diesem Fall wird die Transaktion nicht fortgeschrieben, sondern zurückgerollt (Rollback).

Der Anwendungskern bietet an seiner Schnittstelle fachliche Operationen, in fachliche Komponenten gruppiert, an. Die fachlichen Operationen sind in der Regel zustandslos. Daher ist eine Transaktion über mehrere Aufrufe des Anwendungskerns oder ein Caching über Transaktionsgrenzen hinaus nicht notwendig und nach Möglichkeit zu vermeiden. Ist eine solche Steuerung trotzdem unumgänglich, muss sie über die jeweils zuständige Nutzungsschicht (GUI, Batch oder Service) erfolgen.

Es ist möglich, für Spring-Beans Funktionalität in Form von Aspekten zu definieren. Ihr Einsatz kann über „PointCuts“ konfiguriert werden. Pointcuts definieren (etwa über reguläre Ausdrücke) Klassen und Methoden, welche um den Aspekt erweitert werden.

Zu intensive Nutzung kann leicht zu einem schwer durchschaubaren Programmfluss führen. Deshalb soll AOP nur für folgende Bereichen genutzt werden: die Steuerung von Transaktionen, die Überwachung und die Berechtigungsprüfung.

Explizit nicht benutzt werden soll AOP für die Fehlerbehandlung.

Die Verwendung von AOP für andere Bereiche ist nur in begründeten Ausnahmefällen erlaubt.

Um im Anwendungskern das Single-Responsibility-Prinzip nicht zu verletzten, wird auf das Entwurfsmuster Dependency Injection zurückgegriffen. Dabei werden die Verantwortlichkeiten für den Aufbau des Abhängigkeitsnetzes zwischen den Objekten aus den einzelnen Klassen in eine zentrale Komponente überführt. Anders als bei der herkömmlichen Vorgehensweise in der objektorientierten Programmierung ist bei der Dependency Injection nicht jedes Objekt selbst dafür zuständig, seine Abhängigkeiten (benötigte Objekte und Ressourcen) zu verwalten.

In der folgenden Grafik ist das Entwurfsmuster der Dependency Injection exemplarisch visualisiert.

Die drei verschiedene Verfahren der Dependency Injection sowie die Einsatzszenarien verdeutlicht folgende Übersicht: