Microservices fachlich adäquat schneiden

21. August 2017

Der Schnitt der Servicegrenzen spielt eine wichtige Rolle, denn dieser beeinflusst Faktoren wie Entkopplung, Kommunikation zwischen Services und damit Service-Autonomie und Komplexität. Wie geht man also am besten vor? Welche Methoden und Fallstricke gibt es?

Dieser Beitrag ist der 2. Teil einer Artikelserie zum Thema “Microservices”:

  1. Microservices als Teil der Digitalisierungsstrategie
  2. Microservices fachlich adäquat schneiden
  3. Geschäftsprozesse mit Microservices abbilden
  4. Time to Market mit Microservices DevOps reduzieren

Microservices = Fachlichkeit!

Im letzten Beitrag dieser Serie bin ich auf Microservices allgemein und deren Einsatz als Baustein der Digitalisierungsstrategie eingegangen. Microservices fokussieren auf einen klar abgegrenzten fachlichen Block innerhalb der Fachdomäne, in der man sich bewegt. Jeder Service sollte einen dieser Blöcke als autonomen Softwarebaustein (Self-Contained System) abbilden. Ein Microservices-Team bestehend aus Domänenexperten, Entwicklern und Betrieb übernimmt dabei idealerweise die fachliche und technische Gesamtverantwortung. Die Frage ist jetzt, wie man einen “fachlichen Block” identifiziert!

Ausgangslage

Je nachdem, woher man kommt, unterscheidet sich die Strategie zum Aufspüren der fachlichen Blöcke:

  1. Bei vorhandenem Monolithen ist die Gesamtfachlichkeit der Domäne (oder Teile davon) oft unter einem Dach vereint. Der Vorteil ist, dass alle Beteiligten bereits ein gutes fachliches Verständnis von der Domäne haben. Je nachdem, ob und wie bei der Entwicklung Modularisierung (Separation of Concerns) betrieben wurde, können Module als Grundlage für die Bildung fachlicher Blöcke dienen.
  2. Wenn man auf der “grünen Wiese” beginnt, ist es etwas komplizierter. Vorhandene Organisationsstrukturen können ein erster Indikator für einen fachlichen Schnitt sein. Letztendlich entscheidet aber der Dialog zwischen Fachanwendern (Domain Experts) und Entwicklern bzw. das darüber entwickelte gemeinsame Verständnis. Die Methodik, die mich am meisten überzeugt, ist Domain-Driven Design (DDD). Kombinieren kann man DDD zum Beispiel mit Event Storming; das verhindert ein zu frühzeitiges Fokussieren auf Daten, indem das Hauptaugenmerk zunächst auf fachliche Ereignisse gelegt wird.

Wichtig: Egal, woher Sie kommen, fangen Sie nicht mit einem Datenmodell an! Datenmodelle eignen sich nicht dafür, den richtigen fachlichen Schnitt für einen Microservice zu finden. Sie sind ein Implementierungsdetail!

Bounded Contexts

Der ideale Kandidat für einen Microservice ist ein Bounded Context im Sinne von DDD. Ziel ist die Erreichung hoher fachlicher Kohäsion bei gleichzeitig maximaler Entkopplung zwischen den Services. Aber was genau ist ein Bounded Context?

In hinreichend komplexen Fachdomänen verwenden Personen aus unterschiedlichen Abteilungen oder Gruppen innerhalb des Unternehmens oft unterschiedliche Begrifflichkeiten, um das vermeintlich selbe zu beschreiben. Bildlich gesprochen werden Dinge, Konzepte oder Prozesse innerhalb der Organisation aus unterschiedlichen Blickwinkeln und mit unterschiedlichem Detailgrad gesehen. Eine Vereinheitlichung in einem allumfassenden Softwaremodell würde zur Verwässerung der Bedeutung des betrachteten Konzepts im Kontext der jeweiligen Abteilung führen. Dies sollte vermieden werden! Die Grenzen des jeweiligen Bounded Context werden also dort gezogen, wo diese Bedeutungsnuancen auftreten.

Beispiel

Bounded Contexts sind sicherlich ein auf den ersten Blick schwierig zu greifendes Konzept. Deswegen an dieser Stelle ein kleines Beispiel:

Stellen Sie sich einen Dienstleister vor, der IT-Consulting-Dienstleistungen anbietet; die Domäne des Unternehmens nennen wir deshalb beispielhaft “IT-Consulting-Dienstleister”. Im Unternehmen gibt es zunächst Personen, die sich mit der Akquise von Aufträgen beschäftigen; klassischerweise der Vertrieb und/oder der Verkauf. Gleicherweise gibt es dort Menschen, welche sich um die Abwicklung von Aufträgen kümmern (Service Delivery). Wieder andere erbringen die eigentliche Consulting-Dienstleistung beim Kunden vor Ort. Schließlich müssen die erbrachten Leistungen abgerechnet werden; darum kümmern sich Mitarbeiter der Abrechnung.

Microservices Bounded Contexts

Bedeutungsnuancen finden

Bringt man Menschen in unserem Beispiel-Unternehmen zusammen, kristallisieren sich in Diskussionen über fachliche Zusammenhänge und Prozesse Bedeutungsnuancen heraus, zum Beispiel:

  • Mitarbeiter des Vertriebs sprechen von Kunde im Kontext von Kontakten und Entscheidern, mit denen sie dort in Verbindung stehen.
  • Mitarbeiter der Projektabwicklung (Service Delivery) sprechen von Kunde, wenn Sie Projektverantwortliche und/oder Mitarbeiter auf Kundenseite meinen.
  • Projektmitarbeiter sprechen von einem Projekt, das sie bei Kunde X mit einer bestimmten Laufzeit durchführen. Sie erfassen die dort erbrachten Leistungen im Kontext des Projekts.
  • Die Abrechnung interessiert vor allem, wie die Rechnungsadresse von Kunde X lautet und welche Abrechnungsmodalitäten für die erbrachten Leistungen gelten.

Der Kunde hat für jede dieser Personengruppen also eine unterschiedliche Bedeutung! Ferner sind auch je nach Personengruppe unterschiedliche Attribute des Kunden relevant. Das gleiche gilt für diverse andere Konzepte, z. B. Mitarbeiter. Beispielhaft ist dieses Prinzip in der folgenden Abbildung skizziert. Eine Entität kann natürlich über ihren Schlüssel kontextübergreifend identifiziert werden.

Bounded Contexts für die Fachdomäne "Consulting-Dienstleistung" als Grundlage für Microservices

 

 

Über diese Bedeutungsunterschiede kristallisieren sich unterschiedliche fachliche Konzepte von bestimmten Abläufen im Unternehmen heraus. Das jeweilige fachliche Konzept wird Domain Model genannt und definiert den Bounded Context. Häufig existiert eine 1:1-Beziehung zwischen einer klassischen Unternehmensabteilung und einem Bounded Context. Das muss aber nicht so sein.

Fachlicher Schnitt

Es empfiehlt sich, für jeden identifizierten Bounded Context mit einem Microservice zu starten, der das jeweilige fachliche Konzept implementiert. Kristallisieren sich im späteren Verlauf weitere Bounded Contexts heraus, kann der Schnitt iterativ verfeinert werden. Folgende Punkte sind dabei zu beachten:

  1. Initial lieber mit gröberen Schnitten arbeiten. Diese dann iterativ verfeinern, sofern notwendig.
  2. Technisch getriebene Serviceschnitte vermeiden.
  3. Nanoservices als Anti-Pattern: zu fein geschnittene Services führen zu künstlicher Auftrennung von zusammengehöriger Fachlogik (Verletzung des Cohesion-Prinzips) und damit zu höheren Latenzzeiten, da mehr Kollaboration über das Netzwerk stattfindet.
  4. Umgekehrt führen zu grob geschnittene Services zu “verteilten Monolithen”.

Alternativen?

Natürlich können die Grenzen von Microservices theoretisch auch auf andere Arten gezogen werden. Ideen, die man hierzu findet, sind vielfältig; deshalb hier ein paar Beispiele:

  • Aufteilung von Microservices anhand von Codemetriken, z. B. Lines of Code (LoC)
  • Technische Auftrennung, z. B. horizontal nach Schichten
  • Aufteilung nach geschätztem Entwicklungsaufwand, z. B. nicht länger als eine Woche Entwicklungszeit pro Microservice

Gleich vorweg: Ich persönlich rate von all diesen Ansätzen ab! Die genannten Kriterien konzentrieren sich zu stark auf die Größe der Microservices und weniger auf deren fachlichen Nutzen. Die Gefahr, die darin liegt: Durch die mehr oder weniger “künstliche” Trennung erhöht sich nicht nur der teamübergreifende Abstimmungsaufwand, sondern auch die zwischen den Services laufende Kommunikation. Dies wiederum wird in der Summe nicht zu einer zufriedenstellenden User Experience führen. Zusätzlich entsteht eine enge Kopplung zwischen Services, was wiederum die Vorteile des Microservices-Ansatz insgesamt zunichte macht.

Offene Fragen

Der fachliche Schnitt ist fertig, aber offene Fragen bleiben: Wie verhält es sich bei Geschäftsprozessen, die serviceübergreifend stattfinden, d. h. über zwei oder mehr Bounded Contexts? Wie gehe ich mit “gemeinsamen” Daten abseits der oben beschriebenen Bedeutungsnuancen um? Diese und andere Themen werden in entsprechenden Folgebeiträgen näher beleuchtet.

Fazit

Microservices dienen in erster Linie der Umsetzung von Fachlichkeit, um für das Unternehmen einen Business Value zu erzeugen. Dies geschieht durch Identifikation der Bounded Contexts, die sich über Bedeutungsnuancen innerhalb der Fachdomäne ermitteln. Wichtig ist, dass keine künstlichen oder technisch getriebenen Servicegrenzen definiert und Services nicht zu feingranular geschnitten werden.