All about Context!

Beim Entwerfen von innovativen Microservice-Landschaften sind es vor allem die fachlichen Domänen und deren Beziehungen, die den Schnitt und die Ausgestaltung der Dienste beeinflussen oder gar vorgeben. Domain-driven Design (DDD), im speziellen der Teil des Strategic Design, leistet hierbei Hilfe.

Modernes Design von IT-Landschaften in Banken.

Partner des Bank Blogs

Durch die stetig wachsende Dynamik in den Märkten und im Zuge der Digitalisierung rückt die IT einer Bank heutzutage immer mehr in den Mittelpunkt und ist in vielen Bereichen der kritische Faktor für den Erfolg. Die über viele Jahre gewachsenen monolithischen Systeme können mit der geforderten Reaktionsgeschwindigkeit jedoch meist nicht mithalten, weshalb Ansätze wie eine Microservice-Architektur, Continuous Delivery und agiles Vorgehen immer mehr in den Vordergrund rücken und auch im Bankenumfeld eine immer größere Bedeutung erlangen. Über die Vorteile dieser Ansätze berichtete Anfang des Jahres bereits mein Kollege Baris Cubukcuoglu, Sie finden seinen Beitrag ebenfalls in diesem Blog.

Obwohl der Microservice-Gedanke ein noch recht neuer ist, steht im Hintergrund immer das Ziel einer bedarfsgerechten Modularisierung. Durch unabhängige Deployment-Einheiten, die genau eine fachliche Funktion abbilden und getrennt voneinander in Produktion gebracht werden können, kann so schneller auf die Bedürfnisse des Marktes und der Anwender reagiert werden.

Wie klein ist eigentlich „micro“?

Die Frage, die dabei oft im Raum steht, ist die, wie klein oder groß eigentlich „micro“ ist bzw. welchen Teil einer fachlichen Domäne man am besten in einem Service modularisiert. Eine Herangehensweise, die 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, im Zuge der Microservice-Welle rück er jedoch immer mehr in den Vordergrund. Auf zwei meiner Meinung nach wichtige Werkzeuge daraus, den Bounded Context und die Ubiquitous Language, möchte ich in diesem Artikel etwas genauer eingehen.

Der Bounded Context als Schnittmuster

Domain-driven Design nutzt das Konstrukt des begrenzten Kontextes (Bounded Context), um einen Bereich zu beschreiben, in dem ein Modell eine bestimmte Bedeutung hat. Mit Modell meine ich dabei eine Abbildung der Realität bzw. die Abstraktion eines Problems, dass mittels Software gelöst werden soll. Zugegebenermaßen klingt das im ersten Moment etwas kompliziert, wird aber anhand eines Beispiels relativ schnell verständlich. 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.

Jeder Bounded Context hat sein eigenes Modell des Geschäftspartners.

• Bei der Antragsstellung sind zunächst die persönlichen Daten des Antragstellers, wie der Name und die Adresse relevant.
• Während des Scorings sind beispielsweise Negativmerkmale einer Auskunftei, wie der 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 das 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 bzw. 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. Wichtig ist dabei nur, dass lediglich ein Service bzw. Kontext im Sinne des Command-Query-Responsibility-Segregation-Prinzips (CQRS) die Schreib- bzw. Änderungsrechte besitzt.

In bestimmten Fällen, z.B. aus Gründen besserer Skalierbarkeit kann ein Bounded Context auch in mehrere Microservices aufgeteilt werden, jedoch sollte ein Microservice nie mehr als einen Bounded Context abbilden, womit sich auch die maximale Größe im Sinne von DDD definieren lässt.

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 allgegenwärtigen Sprache, soll innerhalb eines Kontextes ein sprachlicher Rahmen geschaffen werden, der für alle verständlich ist. So kann es dann auch sein, dass in jedem Kontext für Geschäftspartner eine sehr viel spezifischere Bezeichnung vorhanden ist (Antragsteller, Kunde, Debitor) über die auch direkt klar wird, welche Bedeutung der Geschäftspartner denn genau in diesem Kontext hat. Diese Sprache muss sich überall wiederfinden, sowohl die Domänenexperten als auch die Architekten und Softwareentwickler und damit auch Benennungen im Code und in der Datenbank müssen das gleiche Vokabular nutzen.

Nutzung eines einheitlichen Vokabulars durch Einführung der Ubiquitous Language

Gibt es auch eine Untergrenze für einen Microservice?

Nachdem die Begrenzung nach oben durch den Bounded Context bzw. die Ubiquitous Language, die in diesem Kontext gilt, definiert ist, stellt sich die Frage, wie klein denn ein Service sein darf, also welche Logik man möglichst nicht verteilen sollte. Auch hier kann DDD mit seinem Tactical Design weiterhelfen. Dieses stellt Patterns und Werkzeuge bereit, die helfen, die innere Struktur eines Kontextes zu gestalten. Besonders hilfreich sind dabei die sogenannten Aggregates. Man kann sich darunter eine Gruppe von Objekten vorstellen, die im Sinne von Datenänderung- und Integrität eine Einheit bilden. Anders gesprochen soll es keine Transaktionen geben, die Aggregatsgrenzen überschreiten. Zudem wird über den sogenannten Aggregate-Root eine Schnittstelle nach außen definiert. Änderungen an Bestandteilen des Aggregates dürfen also immer nur über diesen erfolgen.

Na dann mal los?

Bevor man Methoden oder Werkzeuge wie DDD im eigenen Unternehmen einführt sollte man sich immer bewusst 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 dies nicht gewährleistet werden bzw. wird es nicht aktiv vom Management gefördert, können potenzielle Reibungspunkte den eigentlich angestrebten Gewinn bzw. Nutzen schnell zunichtemachen.

Partner des Bank Blog – adesso

Mehr über das Partnerkonzept des Bank Blogs erfahren Sie hier.