Seite 2: Design-Prinzipien

Inhaltsverzeichnis

Auch Integrationsarchitekturen müssen den Design-Prinzipien folgen, wie sie aus dem Entwurf für Architekturen ganz allgemein bekannt sind:

• Flexibel: Architekturen sollen flexibel sein, um auf sich ändernde Marktanforderungen und technologische Innovationen reagieren zu können.
• Evolutionär: Architekturen müssen evolutionär sein, um Schritt-für-Schritt-Ansätze zu unterstützen und Big-Bang-Übernahmen in die Produktion zu vermeiden.
• Standardisiert: Architekturen müssen Interface-Architekturen anbieten, die das Standardisieren auch auf Legacy-Anwendungen erlaubt.
• Entkoppelt: Architekturen müssen einzelne Anwendungen entkoppeln, um Abhängigkeiten in Entwicklung und Betrieb gering zu halten.
• Integriert: Unternehmensarchitekturen müssen in der Lage sein, unterschiedliche Backend-Anwendungen zu integrieren, um domänengetriebene Entwicklungen zu ermöglichen.

Modell "Neue Benutzerschnittstelle"

Der erste Schritt auf dem Weg der schrittweisen Ablösung von Legacy-Systemen ist die Definition verbrauchergetriebener APIs (Application Programming Interface). Damit sind sowohl synchrone RESTful APIs als auch asynchrone APIs über Events gemeint. Vorerst kann man sich auf RESTful APIs konzentrieren.

REST (Representational State Transfer) ist ein API-Typ, der webbasierte Applikationen in der Kommunikation unterstützt. Obwohl eine solche API theoretisch mit jedem Protokoll oder Datenformat kompatibel ist, verwendet REST in den meisten Fällen das HTTP-Protokoll und überträgt die Daten mithilfe von JSON (JavaScript Object Notation).

Verbrauchergetriebene REST API heißt, dass der Verbraucher und nicht der Anbieter die Definition der API übernimmt. Mit solchen Definitionen lassen sich oftmals einfacher zu verstehende Schnittstellen hervorbringen, die die Komplexität der Backend-Implementierung verbergen.

Im Beispiel in Abbildung 2 will man die Funktion "Schadensmeldung" aus der Benutzer-Interface-Schicht herauslösen, um Mitarbeitern und Kunden eine einfache Mobil- und Webanwendung zur Verfügung zu stellen. In der API wird eine Ressource "Schadensmeldung" definiert und durch den API-Layer "API Ecosystem" exponiert.

API Ecosystem

Ein API-Ökosystem ist eine Sammlung von APIs, die ein Hersteller oder Dienstanbieter für Externe und Anwender zur Verfügung stellt. Die APIs folgen in der Regel RESTful-Ansätzen. Aber auch entsprechende Events werden definiert und für technische Konsumenten zur Verfügung gestellt.

Im Beispiel in Abbildung 3 wird ein Anti-Corruption-Layer oder auch eine Antibeschädigungsebene eingezogen, um das Legacy-System vom neuen Service zu entkoppeln. Ein Anti-Corruption-Layer ist ein Entwurfsmuster, das verwendet wird, um verschiedene Systeme voneinander zu entkoppeln. Dafür kommen Eventgetriebene Mechanismen zum Einsatz.

Anti-Corruption-Layer

Ein Anti-Corruption-Layer oder auch Antibeschädigungsebene ist eine zusätzliche Schicht in einer Architektur, um Implementierungsdetails eines Backend-Systems von einem Konsumenten zu verbergen. Durch diese Schicht können die Systeme unterschiedlichen Releasezyklen folgen oder auch gewisse Puffer implementieren, die eine höhere Stabilität des Gesamtsystems garantieren. Solche Schichten können auch zusätzliche Mapper darstellen, wo unterschiedliche Inhalte von Geschäftsobjekten übersetzt werden.

Abbildung 3 zeigt einen solchen Eventgetriebenen Anti-Corruption-Layer.

1. Ein Benutzer hat eine Schadensmeldung erzeugt und möchte sie speichern.
2. Diese Speicherung erzeugt einen Post auf die entsprechende Consumer-driven API im API Ecosystem.
3. Da ein Domänendienst "Schadensmeldung" noch nicht zur Verfügung steht, wird der Post an den Anti-Corruption-Layer weitergeleitet.
4. Ein Event-Producer – diejenige technische Implementierung, die Events erzeugen kann – erzeugt den Event für die Schadensmeldung und speichert ihn im Event-Bus ab.
5. Der entsprechende Event wird durch den Event-Consumer vom Event-Bus gelesen. Ein Event-Consumer ist hierbei die technische Komponente, die Events vom Event-Bus lesen kann.
6. Der Event-Consumer leitet die Schadensmeldung als Post zum Mapper.
7. Der Mapper erzeugt die Schadensmeldungs-ID und speichert sie ab.
8. Der Legacy-Mapper bildet die Schadensmeldung auf das Schadensmodell des Legacy-Schadenssystems ab.
9. Der Legacy-Mapper sendet den Schaden an das Legacy-System und empfängt die entsprechende Schadens-ID als Antwort.
10. Der Mapper weist die Schadens-ID der Schadensmeldung zu. Dadurch lassen sich auch spätere Änderungen erfolgreich an das Legacy-System melden.

Der Mapper lässt sich auch ohne Event-Bus betreiben. Zudem ist es möglich, synchron den Post an den Mapper zu senden. Die Entkopplung über den Event-Bus bietet den Vorteil, dass Verfügbarkeiten der Legacy-Systeme nicht auf die Schadensmeldung-Applikation durchgreifen.

Für moderne Frontend-Applikationen ist ein solches Vorgehen empfohlen, wenn sich die Geschäftslogik (noch) nicht anpassen lässt.