All about Context!

Durch die wachsende Dynamik in den Märkten sowie die voranschreitende Digitalisierung rückt die IT einer Bank immer stärker in den Fokus und stellt häufig einen kritischen Faktor für den Unternehmenserfolg dar. Sicherlich ist euch bewusst, dass die monolithischen Systeme einer Bank, die über viele Jahre gewachsen sind, mit der geforderten Reaktionsgeschwindigkeit meist nicht mithalten können. Aus diesem Grund rücken Ansätze wie eine Microservice-Architektur, Continuous Delivery oder agiles Vorgehen auch im Bankensektor immer mehr in den Vordergrund. Wenn ihr euch nochmals einen Überblick über die Vorteile dieser Ansätze verschaffen möchtet, dann werft doch einfach einen Blick in den Blog-Beitrag von Baris Cubukcuoglu zum Thema „Bank meets Microservices and DevOps“.

Obwohl der Microservice-Gedanke noch recht neu ist, steht im Hintergrund immer das Ziel einer bedarfsgerechten Modularisierung. Unabhängige Deployment-Einheiten bilden genau eine fachliche Funktion ab und können getrennt voneinander in Produktion gebracht werden. Auf diese Weise kann wiederum schneller auf die Bedürfnisse des Marktes und der Anwender reagiert werden.

Wie klein ist eigentlich „micro“?

Wie klein oder groß ist „micro“ eigentlich? Welcher Teil einer fachlichen Domäne wird am besten in einem Service modularisiert? Das sind Fragen, die zunächst häufig im Raum stehen. Eine Herangehensweise, die euch hierbei helfen kann, ist Domain-driven Design. Der Ansatz, der von Eric Evans 2003 in seinem gleichnamigen Buch geprägt wurde, ist nicht wirklich neu. Allerdings rückt sein Ansatz im Zuge der Microservice-Welle immer mehr in den Vordergrund. Ich möchte euch im Folgenden zwei „Werkzeuge“, die meiner Meinung nach in diesem Kontext von hoher Wichtigkeit sind, näher vorstellen: den Bounded Context und die Ubiquitous Language.

Der Bounded Context als Schnittmuster

Um einen Bereich zu beschreiben, in dem ein Modell eine bestimmte Bedeutung hat, nutzt Domain-driven Design das Konstrukt des begrenzten Kontextes – den sogenannten Bounded Context. Mit „Modell“ meine ich dabei eine Abbildung der Realität beziehungsweise die Abstraktion eines Problems, das mittels Software gelöst werden soll. Zugegebenermaßen klingt das im ersten Moment etwas kompliziert. Wie ihr allerdings im Folgenden sehen werdet, ist das Ganze aber relativ simpel: Angenommen, eine Bank möchte innerhalb ihrer Domäne „Kreditverkauf“ ein Webportal zur Beantragung von Krediten entwickeln. Die unterschiedlichen Bounded Contexts könnten hierbei Antragsstellung, Scoring und Kreditvergabe sein. Jeder Kontext ist dabei an unterschiedlichen Informationen des Geschäftspartners interessiert.

• Bei der Antragsstellung sind zunächst die persönlichen Daten des Antragstellers, wie etwa Name oder Adresse, relevant.
• Während des Scorings sind beispielsweise Negativmerkmale einer Auskunftei, wie SCHUFA oder Obligos, des Kunden wichtig.
• Bei der Kreditvergabe müssen das Ergebnis aus dem Scoring und das Konto des Debitors bekannt sein.

Jeder Kontext hat damit sein eigenes Modell des Geschäftspartners, was zu einer unabhängigen Änderbarkeit der Microservices führt. Sind im Rahmen der Kreditvergabe noch weitere Informationen über den Kunden aus anderen Quellen relevant, erfordert es nur eine Änderung in diesem Bounded Context. Die Antragsstellung und das Scoring sind nicht davon betroffen.

Sicherlich gibt es immer Kerninformationen, die in jedem Kontext wichtig sind oder benötigt werden. Eine redundante Haltung dieser Daten in unterschiedlichen Datenbanken, die lange Zeit keineswegs erstrebenswert war, ist in Microservice-Architekturen zum Erreichen der Entkopplung jedoch durchaus gewollt. Dabei solltet ihr euch nur merken, dass lediglich ein Service oder Kontext im Sinne des Command-Query-Responsibility-Segregation-Prinzips (CQRS) die Schreib- und Änderungsrechte besitzt.

In bestimmten Fällen – etwa aus Gründen besserer Skalierbarkeit − kann ein Bounded Context auch in mehrere Microservices aufgeteilt werden. Allerdings sollte ein Microservice nie mehr als einen Bounded Context abbilden. Auf diese Weise könnt ihr übrigens auch die maximale Größe im Sinne von Domain-driven Design definieren.

Ubiquitous Language als gemeinsame Sprache zwischen Fachbereich und Entwicklung

In meiner Beispielbeschreibung habe ich bewusst in jedem Kontext eine andere Begrifflichkeit für Geschäftspartner verwendet. Mit der Ubiquitous Language − einer der Grundpfeiler im Domain-driven Design − soll innerhalb eines Kontextes ein sprachlicher Rahmen geschaffen werden, der für alle verständlich ist. So kann es sein, dass in jedem Kontext für Geschäftspartner eine sehr viel spezifischere Bezeichnung vorhanden ist – zum Beispiel Antragsteller, Kunde oder Debitor. Diese Bezeichnungen zeigen euch dann auch eindeutig, welche Bedeutung der Geschäftspartner genau in diesem speziellen Kontext hat. Allerdings solltet ihr euch im Klaren darüber sein, dass sich diese Sprache überall wiederfinden muss. Seien es die Domänenexperten, die Architekten oder die Softwareentwickler - alle müssen das gleiche Vokabular benutzen. Dementsprechend müssen sich die speziellen Benennungen auch im Code und in der Datenbank wiederfinden.

Gibt es auch eine Untergrenze für einen Microservice?

Nachdem die Begrenzung nach oben durch den Bounded Context oder die Ubiquitous Language definiert ist, stellt sich die Frage, wie klein denn ein Service sein darf. Auch hier kann euch Domain-driven Design mit seinem Tactical Design weiterhelfen. Hier werden euch nämlich Patterns und Werkzeuge bereitgestellt, die euch dabei helfen, die innere Struktur eines Kontextes zu gestalten. Besonders hilfreich sind dabei die sogenannten „Aggregates“. Unter diesem Begriff könnt ihr euch eine Gruppe von Objekten vorstellen, die im Sinne von Datenänderung und Integrität eine Einheit bilden. Mit anderen Worten: Es soll keine Transaktionen geben, die Aggregatsgrenzen überschreiten. Zudem wird über den sogenannten Aggregate Root eine Schnittstelle nach außen definiert.

Na dann mal los?

Bevor ihr Methoden oder Werkzeuge wie Domain-driven Design im eigenen Unternehmen einführt, solltet ihr euch darüber im Klaren sein, dass dies oft auch Auswirkungen auf die Organisationsstrukturen hat. Entwickler müssen sich stärker mit der Fachlichkeit beschäftigen und Domänenexperten sollten ein gutes technisches Verständnis mitbringen. Kann das nicht gewährleistet werden oder wird es nicht aktiv vom Management gefördert, können potenzielle Reibungspunkte den eigentlich angestrebten Gewinn oder Nutzen schnell zunichtemachen.

Dieser Beitrag ist auch im Banken-Blog erschienen.