Kanonisches Modell
Das kanonische Modell von Schleupen.CS besteht aus dem Kanonischen Datenmodell und dem Kanonischen Servicemodell.
Die Typen von Schleupen.CS sind derart designed, dass die Business-Entitäten kanonisch, d.h. im sogenannten Kanonischen Datenmodell eineindeutig sind. Beispiel: ein Vertrag ist immer ein Vertrag, den es als Typ genau einmal gibt. Im kanonischen Servicemodell wird dann diese Business-Entität referenziert und auf die für den spezifischen Service notwendigen Attribute und Assoziationen maßgeschneidert: Jeder Service verwendet nur die für ihn relevanten Attribute und Assoziation. In diesem Sinne ist das kanonische Datenmodell ein Analysemodell, welches keine direkte Entsprechung in Schleupen.CS-Softwareartefakten hat (Xml-Schema o.ä.). Dies ist ein wesentlicher Unterschied im Vergleich zu klassischen kanonischen Datenmodellen.
Das Kanonische Datenmodell ist im DDD Sinne die Blaupause für eine harmonisierte Published Language. Die Summe der Modelle der Service-Fassaden, die auf dem Kanonischen Datenmodell von Schleupen.CS basieren, nennen wir das Kanonische Servicemodell (KSM)
Durch die Verwendung einer harmonisierten Published Language sind Übersetzungen zwischen dem auf dem Service Bus gültigen Kanonischen Datenmodell und Services die eine Fassade des Kanonischen Servicemodell verwenden nicht mehr nötig. Im Übergang zwischen den der Published Language und der Ubiquitous Language eines Bounded Context ist ein Datentransformation erforderlich (siehe auch ACL).
Diese Transformation findet im Microservice mithilfe von Assemblern statt. Somit gibt es im Gegensatz zu klassischen Enterprise Service Bus Architekturen mit einer Transformation über einen Mapper an der Busgrenze, keinen globalen Kopplungspunkt. Wir werden hierauf in der Mikroarchitektur zurückkommen.
Kanonisches Datenmodell (KDM)
Das kanonische Datenmodell (KDM) von Schleupen.CS ist ein analytisches Datenmodell, das mithilfe der UML die Datenzusammenhänge der Serviceebene beschreibt. Wir bezeichnen es als analytisch, da in jeden Service nur die relevante Teilmenge an Attributen und Assoziationen usw. kopiert wird. In Gänze existiert das Modell nicht in der Software (das würde ansonsten zu großen Wartungsproblemen führen!). Die Grundstruktur des KDMs ist durch die Kontinent- und Länder (Domänen und Subdomänen) vorgegeben.
In Modell werden Kontinente und Länder durch Kürzel angegeben und in UML als Packages repräsentiert. Wie in der Abbildung ersichtlich, ist das Modell hierarchisch. Aber nicht nur Kontinente und Länder sind auf oberster Ebene ein Ordnungs- und Strukturierungskriterium, sondern auch das Pendant auf Geschäftsprozessebene durch die sogenannten Geschäftsprozessbündel und Geschäftsprozesskomponenten.
Eine tiefergehende fachliche Unterteilung ist auf allen Ebenen möglich und vorhanden. Das Modell selber wird durch mehrere Klassendiagramme dargestellt, die jeweils nur einen Teilausschnitt des Gesamtmodells sind.
Kanonisches Servicemodell (KSM)
Die Schnittstellen der Services und Events werden ebenfalls in UML modelliert und beschreiben insbesondere deren Datenaustauschformat. Aus diesen UML-Modellen wird dann jeweils eine WSDL für die technische Realisierung generiert (Contract First). Das kanonisches Servicemodell (KSM) ist analog zum KDM hierarchisch durch Packages strukturiert, die die Kontinent- / Land-Struktur bzw. Geschäftsprozess-Bündel und Geschäftsprozesskomponenten abbilden.
Die Blätter des kanonisches Servicemodells sind die Services, die als Postfix die Servicekategorie im Namen tragen. Alle Services, die unter einem Land definiert werden, gehören zu diesem.
Im Bild ist der MesskonzeptQueryService zur Abfragen von Daten zu sehen. Unter dessen Package befinden sich noch die zueinander inkompatiblen Versionen - beispielsweise 3.0 und 3.1, die ebenfalls als UML-Package modelliert werden. Der Service selbst wird als UML-Diagramm dargestellt, welches den Service als UML-Interface inklusive Operationen und von diesen verwendeten Typen beschreibt.
Bei der Definition der Services gibt es einige wichtige Regeln, die zu beachten sind. So darf eine Serviceversion beispielsweise nur Klassen aus dem eigenen Package verwenden, da die Services auch auf Typebene loose gekoppelt sein sollen und es keine Kopplung der Schnittstellen geben darf. Eine Konsequenz hieraus ist, dass die Datentypen des KDM nicht direkt im KSM bzw. Service verwendet werden. Die in einem Service verwendeten Typen werden dupliziert und mit den Datentypen des KDM verlinkt. Zur Erinnerung: Das KDM ist ein analytisches Modell, eine Blaupause.
Die Verlinkung zwischen KSM und KDM Typen ermöglicht eine Impact-Analyse. Diese ist wichtig, um die Auswirkungen einer Änderung von Entitäten in Bezug auf die betroffenen Services analysieren zu können..
Verfahren zur Definition einer Serviceschnittstelle
Folgendes Verfahren wird verwendet, um die Schnittstellen auf den Anwendungskontext maßzuschneidern und die Servicemodelle zu erstellen:
Nehmen wir an, wir möchten einen BuecherAusleihenActivityService modellieren, der es ermöglicht, Bücher für einen Benutzer auszuleihen.
- Im ersten Schritt sind die benötigten Typen des KDMs, die man gedanklich auswählt: man wählt quasi den Bereich des kanonischen Datenmodells aus, der relevant ist:
Das Benutzerkonto wird hier nicht mit ausgewählt, da die Benutzerinformation bereits durch das SessionToken transportiert wird.
- Nun werden die nicht benötigten Assoziationen gekappt:
- Analog werden nur die relevanten Attribute ausgewählt:
- Die vorherigen Schritte führt man gedanklich durch, so dass man mittels Tooling die Typen in die Service-Definition dupliziert:
Vorteilhaft an diesem Verfahren ist, dass die Struktur des KDMs im Servicedesign erhalten bleibt, da die Beziehungen der Business-Entitäten erhalten bleiben. Das Servicedesign bleibt aus Nutzungssicht somit nachvollziehbar!
Um eine sogenannte Impact-Analyse durchführen zu können, sind das kanonische Datenmodell und das kanonische Servicemodell miteinander verlinkt. Damit ist es dann einfach möglich, Auswirkungen von Änderungen des kanonischen Datenmodells auf die Services herauszufinden. Mithilfe der Impact-Analyse soll eine kontrollierte Durchführung von Änderungen ermöglicht werden, um negative Auswirkungen auf das System oder Projekt zu verhindern. Unserer Erfahrung nach ist dies unproblematisch.
Die Aufteilung von KDM und KSM hat sich als fruchtbare Aufteilung der Zusammenarbeit von Analyst und Entwickler erwiesen.