Das reaktive Manifest ist der Versuch, die Werte für einen Architekturstil zu definieren, der das Ziel verfolgt, robuste, fehlertolerante und gut skalierbare Systeme zu schaffen. Nachrichten-orientierte Kommunikation zwischen den Diensten ist ein weiteres wichtiges Ziel dieses Architekturstils. Viele dieser Ziele erreichen wir durch die Nutzung moderner Technologien für die Nachrichtenverteilung, z.B. Kafka oder RabbitMQ, und Nachrichtenverarbeitung, z.B. Storm oder Flink.

Nachrichten sind ein wesentlicher Bestandteil der Schnittstelle solcher Dienste. Wie bei jeder anderen Schnittstelle machen wir uns vor der Entwicklung Gedanken, wie wir sie gestalten, technisch und fachlich. Bei Nachrichten legen wir fest, welche Eigenschaften so eine Nachricht hat. Nachrichten nutzen wir, um einen aktuellen Zustand oder eine Veränderung eines Zustandes zu melden. Nachrichten werden gruppiert (z.B. nach Ort oder Zeit), können zu größeren Nachrichten aggregiert oder in viele kleine Nachrichten zerlegt werden. Manche Nachrichten haben eine Gültigkeit und werden verworfen, wenn sie veraltet sind.

Motivation

Mit dem Baustein Event wollen wir Nachrichten eines Systems beschreiben, weitestgehend unabhängig vom Architekturstil und der gewählten technischen Lösung. Dabei steht der fachliche Nutzen der Nachricht im Vordergrund. In einem agilen Projekt können wir die Entscheidung für die technische Umsetzung getrost dem cross-funktionalen Team überlassen.  Die Technologie für die Nachrichtenverteilung und Nachrichtenverarbeitung hat große Auswirkungen auf die Realisierung von Nachrichten und muss immer durch eine Entscheidung mit dem Baustein Decision begründet werden.

Wichtig ist, dass der Baustein Event dafür gedacht ist, einer Nachricht eines Systems einen eindeutigen Namen zu geben. Der Name der Nachricht wird auch im Code verwendet und schlägt damit die Brücke zwischen Wiki und Code. Die Struktur einer Nachricht beschreiben wir direkt in der Klasse (z.B. javadoc) oder formal mit einem XML-, AVRO– oder JSON-Schema.

Code und andere Artefakte der Entwickler in einem Code-Repository sind somit Teil der Dokumentation. Ein Leser der Produktdokumentation wird durch den Baustein Event in die Lage versetzt, den Code für eine Nachricht zu finden und zu verstehen.

Weitere Quellen

Es gibt eine Reihe von Ansätzen, die Software-Architektur quasi als wissenschaftliche Disziplin betrachten, Kernaufgaben des Architekturentwurfs definieren und Vorlagen für die Dokumentation zur Verfügung stellen.

Zuerst erfasst man ein “Architecture Principle”, welches die Nutzung von Nachrichten erklärt (das “Statement”) mit seinen Randbedingungen (das “Rationale”) und Auswirkungen (die “Implications”).

Das Kapitel 35 mit dem Titel “Architectural Artifacts” zeigt die unzähligen Möglichkeiten für die Darstellung des Systems (“View”) aus einer bestimmten Perspektive (“Viewpoint”) für einen bestimmten Aspekt der Funktionsweise des Systems (“Concern”).

Mit dem Begriff “Data Architecture” werden ganz konkret Diagramme vorgestellt, die geeignet sind, Nachrichten in allen Perspektiven, also statische und dynamische Sicht, darzustellen.

Quelle: TOGAF9 online documentation

(

In der Bausteinsicht wird die statische Zerlegung des Systems in Bausteine (Module, Komponenten, Subsysteme, Teilsysteme, Klassen, Interfaces, Pakete, Bibliotheken, Frameworks, Schichten, Partitionen, Tiers, Funktionen, Makros, Operationen, Datenstrukturen, …) sowie deren Beziehungen dokumentiert. Nachrichten sind in erster Linie Datenstrukturen. Das Zusammenspiel der Bausteine wird in der Laufzeitsicht beschrieben.

Quelle: ARC42 online documentation

Definition

Beschreibung

Der Baustein Event beschreibt ein Nachrichtenobjekt des Systems und gibt ihm einen eindeutigen Namen. Der Name des Bausteins wird auch im Code-Repository für die Implementierung des Nachrichtenobjektes verwendet und schlägt damit die Brücke zwischen Wiki und Code.

Der Baustein Event wird für Entwickler geschrieben. Ein Nachrichtenobjekt ist eine Schnittstelle in einer event-basierten Architektur.

Struktur

Abschnitt Steckbrief

Der Abschnitt enthält eine Tabelle mit Zeilen für eine Kurzbeschreibung und die Kategorie des Nachrichtenobjektes.

ktip Der Steckbrief sollte so gestaltet werden, dass sich aus dem Namen, der Kurzbeschreibung und der Kategorie sehr leicht ein Katalog erstellen lässt. In Confluence nutzen wir das Makro Seiteneigenschaften für den Steckbrief. Der Katalog wird mit dem Makro Seiteneigenschaftsbericht erstellt.
Abschnitt Eigenschaften

Der Abschnitt enthält eine Tabelle mit den fachlichen Eigenschaften des Nachrichtenobjektes. Jede Eigenschaft hat einen Namen und eine Beschreibung.

ktip Ein Nachrichtenobjekt hat auch technische Eigenschaften, z.B. eine techische ID, eine Correlation-ID oder einen Zeitstempel. Diese technischen Eigenschaften werden mit dem Baustein Spec als gemeinsames Konzept beschrieben.
Abschnitt Spezifikation

In diesem Abschnitt befindet sich die exakte Definition des Nachrichtenobjektes, , während die Abschnitte davor ein Verständnismodell für das Nachrichtenobjekt beschreiben. Eine konkrete Implementierung kann im Detail von diesem vereinfachten Modell abweichen. Eine Implementierung muss nicht alle Attribute oder Elemente realisieren und kann weitere Attribute hinzufügen, wenn es für die Implementierung notwendig ist. Die konkreten Datentypen werden ausschließlich in der Spezifikation festgelegt.

ktip Der Abschnitt liegt in der Verantwortung des Entwicklerteams. Es bietet sich an, ein Artefakt (z.B. eine Schemadefinition) direkt aus dem Code-Repository zu verwenden und Confluence für die Veröffentlichung der Inhalte zu nutzen.