Länder

Domains - Länder & Kontinente

Schleupen.CS ist gemäß der Prinzipien des Domain-Driven Designs in Domänen und Subdomänen unterteilt. Dabei teilen die Anwendungsdomänen Schleupen.CS in fachliche Bereiche ein, um eine gute Strukturierung der darin befindlichen Bausteine zu erzielen. Diese Domänen werden in Schleupen.CS Kontinente genannt.

Ein Kontinent fasst die fachliche Funktionalität der Anwendungsdomäne zusammen, trifft dabei aber keine Aussage zur deren Umsetzung. Eine Anwendungsdomäne wird in Subdomänen, im Schleupen Sprachgebrauch Länder genannt, unterteilt. Im Sinne des Domain-Driven Designs ist jedes Land auch ein Bounded Context.

Wir werden später noch sehen, dass es Länder gibt, die mehrere Bounded Contexts enthalten. Diese zusätzlichen Bounded Contexts nennen wir im Schleupen-Sprachgebrauch Provinzen. Dies sei hier nur der Vollständigkeit halber erwähnt und kann für das Verständnis der Makroarchitektur zunächst außer Acht gelassen werden.

DRY – Don‘t-repeat-yourself

Da die funktionalen Anforderungen der verschiedenen Szenarien häufig starke Überschneidungen haben, ist es unser Ziel, die Implementierung der Anwendungsdomäne möglichst wiederverwendbar zu gestalten und neue Anwendungslandschaften durch Rekombination der vorhanden Länder zusammenzustellen. Damit dies möglich ist, muss die Verwendung in verschiedenen Szenarien beim Zuschnitt der Länder berücksichtigt werden. Ziel ist es, nur die erforderlichen Subdomänen für ein Szenario bereitzustellen.

Microservices

Damit eine einfache Rekombinierbarkeit von Ländern möglich ist, muss ein Land Funktionen bereitstellen, die den fachlichen Kontext kapseln. Funktionen eines Landes (z.B. 'Leihe Buch aus' oder 'Frage Bücher von Autor Martin Fowler ab') werden als Services bereitgestellt.

Die einzelnen Länder stellen ihre Funktionalität in Form von Webservices bereit und genügen den folgenden Charakteristika von Microservices:

• isolierte Entwicklung
• sehr gut wart- und testbar
• lose gekoppelt
• unabhängig deploybar
• anhand von geschäftlichen Fähigkeiten organisiert
• hohe funktionale Kohäsion
• durch ein Team verantwortet

Bei der Umsetzung von Microservices wird das Ziel verfolgt, diese möglichst zu isolieren und sehr auf deren Autonomie zu achten. Als erster wichtiger Vorteil ist hier die Autonomie der Teams hinsichtlich der Implementierung und der Auslieferung der Software zu nennen. Hierdurch erreicht man aber auch eine Isolation der Bausteine zur Laufzeit. Im Fehlerfall, im schlimmsten Fall - bei einem Crash - stirbt nur dieser eine Microservice, der Rest des Systems bleibt funktionsfähig. Darüber hinaus wirkt sich die Autonomie positiv bezüglich der Fähigkeit zur horizontalen Skalierung aus (Stichwort: Container). Ziel ist es, die Elastizität moderner Cloud-Umgebungen nutzen zu können. 

Die Microservices von Schleupen.CS stellen Services zur Umsetzung der Geschäftsprozesse bereit, die eine zielgerichtete, aktive Nutzung ermöglichen. In der Abbildung sind diese als blaue Lollipops dargestellt. Die grauen Lollipops hingegen sind reaktiv: Tritt ein fachliches Ereignis ein, so wird ein sogenanntes Business Event ausgelöst. Dieses kann ein beliebiger Baustein (Land oder Geschäftsprozesskomponente) abonnieren, um über diese Ereignisse informiert zu werden.

Persistenz - Lose Kopplung auch auf Datenebene

In der Vergangenheit wurden Anwendungen häufig auf Service-, nicht aber auf Datenebene getrennt. Eine echte Rekombinierbarkeit war damit nicht gegeben. Die oben beschriebenen Anforderungen an Microservices waren nicht zu erreichen.

Eine Isolation auf Persistenzebene vereinfacht neben obiger Charakteristika insbesondere den Test eines Microservice, da nur dessen Daten notwendig sind.

Es ist eine essenzielle Eigenschaft von Schleupen.CS, dass keine Kopplung der Länder (Microservices) auf Datenebene existiert. Diese Randbedingung ist auch von Ländern einzuhalten, die nicht auf der Mikroarchitektur von Schleupen.CS basieren!

Schleupen.CS nutzt in der Regel relationale Datenbanken für die Speicherung der Daten von Ländern. Die Struktur und Beziehungen der Daten eines Landes, werden in einem DB-Schema gekapselt. Darüber hinaus stellt das DB-Schema einen Namensraum zur Verfügung und vermeidet so Namenskollisionen, die entstehen könnten, wenn Schemata mehrerer Länder in einer DB erstellt werden.

Im Beispiel wird das Land Schleupen.AS.MT.BIB_Bibliotheksverwaltung dargestellt, welches das DB-Schema MT_BIB exklusiv besitzt. Dieses kann in einer separaten Datenbank oder mit Schemata anderer Länder gemeinsam in eine DB-Instanz deployed werden. Im folgenden Beispiel ist die Datenbank DB11_2 exemplarisch in eine eigene Datenbank extrahiert worden, was einer Konfigurationsänderung entspricht.

Wir werden sehen, dass das Modell im Bild zwar für die Arbeit eines Programmierers ein gute Näherung ist, die Ist-Situation aber noch nicht vollständig beschreibt. Es fehlt noch der hierzu querschnittliche Aspekt der Zugehörigkeit der Daten zu Mandanten, d.h. die Berücksichtigung der Systemtrennung.

Systemstruktur - getrennte Daten von Mandanten

Schleupen.CS verfügt über eine hierarchische Systemstruktur, die im Kontext der Datentrennung eine wichtige Rolle spielt: Die regulatorischen Anforderungen verlangen eine systemische Trennung der Daten unterschiedlicher Marktrollen. Marktrollen sind Elemente in der Systemstruktur. Aus diesem Grund hat jedes Element der Systemstruktur (mindestens) eine eigene DB-Instanz.

Bei der Konfiguration des Systems wird festgelegt, welche Services auf welchem Element der Systemstruktur "erreichbar" sein sollen (siehe ServiceImplementationGroup (SIG)). Dadurch entsteht eine Verbindung zwischen dem Land, dass den Service bereitstellt und dem Systemstrukturelement, dass über das der Service erreichbar ist. In diesem Sinne kann das DB-Schema als querschnittlicher Aspekt der Systemstruktur verstanden werden.

Die Daten der Systemstrukturelemente sind vollständig voneinander getrennt. Das DB-Schema eines Landes, das mit verschiedenen Systemstrukturelementen verbunden ist, wird in den Datenbanken aller dieser Elemente angelegt.  

Aus Sicht eines Schleupen.CS-Service-Entwicklers erfolgt die Implementierung quasi unabhängig von dieser Systemstruktur: Die Infrastruktur der Plattform sorgt dafür, dass jeder Service-Aufruf das sogenannte Session Token mitliefert. Das Session Token enthält den Datenkontext, über den die zugeordnete Datenbank ermittelt wird. Der Datenkontext definiert die zu verwendende Datenbank für diesen Serviceaufruf. Im Standard wird pro Element der Systemstruktur eine Datenbank konfiguriert - die sogenannte "Standard"-Datenbank.

Der Transportweg des Session Tokens ist ein Implementierungsdetail der Plattform. Aktuell wird dieses über den SOAP-Header transportiert.

Anmerkung: Das Konzept der Systemstruktur geht über das Festlegen des Datenkontextes hinaus, dies ist aber an dieser Stelle nicht relevant!

Per Konfiguration ist es einfach möglich, einem Systemstrukturelement mehrere Datenbanken zuordnen. Dies ist dann sinnvoll, wenn aus administrativen Gründen und aufgrund von Skalierung, Last-Verteilung, etc. nicht alle Schemata der Länder mit Verbindung zum Systemstrukturelement in einer Datenbank angelegt werden sollen. Dabei darf das Datenbankschema eines Landes nur genau einer Datenbank eines Systemstrukturelementes zugeordnet sein.

Betrachten wir zum besseren Verständnis das in nachfolgender Abbildung dargestellte Beispiel. Nehmen wir an, dass das Land Schleupen.AS.MT.BIB_Bibliotheksverwaltung mit den Mandanten 1, 2, 10 und 11 verknüpft ist. Ohne spezielle Konfiguration wird das Schema zum Land gehörende Schema MT_BIB für die Mandanten 1, 2 und 10 in deren Standard Datenbanken DB_1, DB_2 und DB_10 erstellt. Im Falle von Mandant 11 soll MT_BIB aber nicht in der Standarddatenbank DB_11 angelegt werden, sondern in einer anderen Datenbank, DB_11_2. Dafür ändert ein Operator die Konfiguration so, dass das Schema MT_BIB für Mandant 11 in der Spezialdatenbank DB_11_2 angelegt wird. Das Session Token für Aufrufe von Services des Landes Schleupen.AS.MT.BIB_Bibliotheksverwaltung wird bei Ausführung im Kontext des Systemstrukturelementes Mandant 11 nun die Datenbank DB_11_2 über den Datenkontext liefern, für alle Services anderer Länder aber weiterhin die Standard-Datenbank DB_11.

Das CS 3.0 System lässt sich also auch so betreiben, dass jeder Microservice eine eigene Datenbank pro verbundenem Systemstrukturelement hat.

Da die Anzahl an Datenbanken für eine Schleupen.CS Installation schnell in einem vierstelligen Bereich liegen kann, wird ein Schleupen.CS 3.0-System initial mit den "Standard"-Datenbanken eingerichtet. Dies steigert die Effizienz bei der Einrichtung des Systems. im Allgemeinen ist eine weitere Aufteilung in Datenbanken nicht notwendig und würde einige administrative Herausforderungen mit sich bringen.