Microservices-Schnitt mit Claude entwerfen: Bounded Contexts finden

1. Warum der Zuschnitt die schwierigste Entscheidung im System ist

Anders als ein Namenskonflikt in einer Codebasis oder eine unsaubere Klassenhierarchie lässt sich ein falscher Servicezuschnitt nicht mit einem Refactoring-Commit korrigieren. Sobald zwei Services über eine öffentliche API kommunizieren, in unterschiedlichen Repositories liegen und von unterschiedlichen Teams betrieben werden, wird jede Grenzverschiebung zu einer Migration mit Versionierung, Übergangsphasen und Koordinationsaufwand über Teamgrenzen hinweg. Die Kosten eines falschen Schnitts zeigen sich deshalb oft erst Monate nach der Entscheidung, wenn Teams laufend über Servicegrenzen hinweg synchronisieren müssen.

Genau deshalb lohnt sich zusätzlicher Aufwand am Anfang. Claude kann in dieser Phase als schneller Gesprächspartner dienen, der Domänenwissen strukturiert, Optionen durchspielt und Rückfragen stellt, die im Alltag oft untergehen. Wichtig ist dabei die Erwartungshaltung: Claude liefert keine fertige Architektur zum Abnicken, sondern arbeitet am besten iterativ, mit echtem Domänenwissen aus dem Team als Eingabe und kritischer Prüfung der Ausgabe.

2. Bounded Contexts aus der Fachdomäne ableiten lassen

Der saubere Ausgangspunkt für einen Microservices-Schnitt ist nicht die technische Infrastruktur, sondern das Domain-Driven-Design-Konzept des Bounded Context: ein fachlicher Bereich, in dem ein Begriff wie Kunde oder Bestellung eine konsistente, in sich abgeschlossene Bedeutung hat. Claude kann helfen, aus einer Beschreibung der Fachprozesse Kandidaten für solche Kontextgrenzen abzuleiten, insbesondere wenn man ihm explizit Ubiquitous-Language-Begriffe, Prozessabläufe und bekannte Inkonsistenzen zwischen Abteilungen liefert.

Entscheidend ist die Qualität des Prompts: Statt nur nach einer generischen Microservices-Aufteilung zu fragen, liefert man Claude ein Domänenglossar, eine Liste bestehender Datenbanktabellen mit ihren Beziehungen und eine kurze Beschreibung, wo im Unternehmen Begriffe wie Produkt heute schon unterschiedlich verwendet werden. Solche semantischen Brüche sind oft die zuverlässigsten Signale für eine echte Bounded-Context-Grenze.

# Beispiel-Prompt für Claude Code: Bounded Contexts aus Domänenwissen ableiten
claude "Hier ist unser Domänenglossar (glossar.md) und eine Liste der
Kernprozesse (prozesse.md) für unseren B2B-Grosshandel. Identifiziere
Kandidaten für Bounded Contexts nach DDD. Für jeden Kandidaten:
- Kernverantwortung in einem Satz
- Welche Entitäten/Aggregate gehören dorthin
- Wo der Begriff 'Kunde' in unterschiedlichen Bedeutungen auftaucht
- Offene Fragen, die ich mit dem Fachbereich klären muss
Schlage KEINE fertige Microservices-Architektur vor, nur die fachlichen
Grenzen als Diskussionsgrundlage.

3. Trade-off: Wenn der Schnitt zu fein gerät

Ein zu feiner Zuschnitt entsteht typischerweise, wenn technische statt fachliche Kriterien den Schnitt bestimmen, etwa ein eigener Service pro Datenbanktabelle. Das Ergebnis ist oft ein Distributed Monolith: viele kleine Services, die bei nahezu jeder Anfrage synchron miteinander reden müssen, wodurch die Latenz steigt und Fehler sich über Servicegrenzen hinweg fortpflanzen. Chatty Services dieser Art verlieren die eigentlichen Vorteile von Microservices, nämlich unabhängige Deploybarkeit und Fehlerisolation, während sie gleichzeitig den vollen operativen Overhead von verteilten Systemen mitbringen.

Claude kann bei der Erkennung solcher Muster helfen, indem man ihm eine Liste geplanter Services mit ihren Aufrufbeziehungen vorlegt und explizit nach synchronen Aufrufketten fragt, die über mehr als zwei Hops gehen. Solche Ketten sind ein starkes Warnsignal dafür, dass zusammengehörige Fachlogik künstlich auseinandergerissen wurde und eher als ein einziger Service oder über asynchrone Events modelliert werden sollte.

4. Trade-off: Wenn der Schnitt zu grob gerät

Am anderen Ende des Spektrums steht der zu grobe Schnitt, bei dem mehrere fachlich unabhängige Verantwortlichkeiten in einem einzigen Service landen, etwa Bestellabwicklung und Rechnungsstellung zusammen. Das äußert sich zunächst nicht in Performanceproblemen, sondern in Deploy-Kopplung: Ein Team, das nur die Rechnungslogik ändern will, muss den gesamten Service testen und ausliefern, inklusive aller Bestell-Funktionalität, die von diesem Change gar nicht betroffen ist. Release-Zyklen verlangsamen sich, und die Verantwortlichkeit für Bugs verschwimmt zwischen Teams.

Ein hilfreiches Signal, das Claude beim Review herausarbeiten kann, ist die Frage nach unabhängigen Änderungsgründen im Sinne des Single-Responsibility-Prinzips auf Servicelevel: Ändern sich zwei Funktionsbereiche eines Services aus unterschiedlichen fachlichen Gründen und zu unterschiedlichen Zeitpunkten, ist das ein Indiz für einen zu groben Schnitt, selbst wenn beide Bereiche technisch eng verzahnt erscheinen.

5. Claude als Sparringspartner statt als Entscheidungsinstanz

Der wichtigste methodische Punkt bei der Arbeit mit Claude an Architekturfragen ist die Rollenaufteilung: Claude generiert Optionen, macht implizite Annahmen sichtbar und stellt Fragen, die im Alltagsgeschäft übersehen werden, trifft aber nicht die letzte Entscheidung. Architekturentscheidungen tragen politische, organisatorische und historische Komponenten, die Claude nicht kennt, etwa welches Team bereits Erfahrung mit einer bestimmten Technologie hat oder welcher Bereich in sechs Monaten ausgegliedert werden soll.

In der Praxis bewährt sich ein Muster, in dem ein Architekt Claude bewusst als Advocatus Diaboli einsetzt: Nach einem ersten Entwurf wird Claude gebeten, gezielt Gegenargumente für den gewählten Schnitt zu suchen, etwa versteckte Kopplungen oder Datenkonsistenzprobleme über Servicegrenzen hinweg. Diese Rolle als kritischer Prüfer, nicht als Entscheider, liefert oft mehr Wert als eine direkte Bitte um eine fertige Architektur.

# Claude gezielt als kritischen Prüfer einsetzen, nicht als Entscheider
claude "Hier ist unser Architekturentwurf für 6 Services (architektur.md).
Spiele Advocatus Diaboli: Finde die drei stärksten Gegenargumente gegen
diesen Schnitt. Konzentriere dich auf:
- Versteckte Datenkopplung zwischen Services
- Transaktionsgrenzen, die über Services hinweg nötig wären
- Fälle, in denen zwei Services fast immer gemeinsam geändert werden
Triff KEINE Entscheidung, liefere nur die Gegenargumente mit Begründung.

6. Wie viel Kontext Claude für belastbare Vorschläge braucht

Ein generischer Prompt wie Entwirf mir eine Microservices-Architektur für einen Online-Shop liefert generische Antworten aus Lehrbuchwissen, die selten zur konkreten Organisation passen. Belastbare Ergebnisse entstehen erst, wenn Claude Zugriff auf reale Artefakte bekommt: bestehende Datenmodelle, aktuelle Teamstruktur, historisch gewachsene Kopplungen und bekannte Schmerzpunkte im aktuellen System. Ohne diesen Kontext extrapoliert Claude aus allgemeinen Mustern, die zwar plausibel klingen, aber die tatsächliche Domäne verfehlen können.

Ein oft unterschätzter Faktor ist Conway's Law: Die Kommunikationsstruktur einer Organisation spiegelt sich zwangsläufig in der Softwarearchitektur wider. Ein Servicezuschnitt, der der bestehenden Teamstruktur widerspricht, etwa weil ein Service von drei verschiedenen Teams gepflegt werden müsste, wird in der Praxis kaum funktionieren, unabhängig davon, wie sauber er fachlich modelliert ist. Diese organisatorische Realität sollte man Claude explizit als Randbedingung mitgeben.

7. Praxisbeispiel: Eine E-Commerce-Domäne zerlegen

Konkret lässt sich das am Beispiel einer Bestellabwicklung zeigen. Statt eines einzigen OrderService, der Bestellerfassung, Zahlungsabwicklung, Versand und Retouren zusammenfasst, kann eine Diskussion mit Claude typischerweise vier fachlich unterscheidbare Kontexte herausarbeiten: Order Management als Kern der Bestellerfassung, Payment als eigenständiger Kontext mit eigener Konsistenzanforderung wegen regulatorischer Vorgaben, Fulfillment für Lager und Versand, sowie Returns als eigener Prozess mit anderem Lebenszyklus als die ursprüngliche Bestellung.

Wichtig bei diesem Beispiel ist, dass Claude die Grenzen nicht einfach vorschlägt, sondern die Begründung transparent macht: Payment wird oft als eigener Service ausgekoppelt, weil dort andere Compliance-Anforderungen wie PCI-DSS gelten und ein anderes Team mit spezialisiertem Wissen verantwortlich zeichnet, nicht primär aus technischen Skalierungsgründen. Diese Art von Begründung lässt sich mit dem Fachbereich validieren, eine reine Diagrammausgabe ohne Begründung dagegen kaum.

8. Eine Review-Checkliste für Claude beim Architektur-Check

Statt Claude bei jedem Review neu zu erklären, worauf es ankommt, lohnt sich eine feste Checkliste, die man wiederholt als Prompt-Grundlage verwendet: Datenownership pro Service eindeutig, keine geteilte Datenbank zwischen Services, klare Transaktionsgrenzen ohne verteilte Zwei-Phasen-Commits, synchrone Aufrufketten unter drei Hops, und für jeden Service ein einzelnes Team, das die volle Verantwortung trägt. Diese Kriterien lassen sich in ein wiederverwendbares Prompt-Template gießen, das bei jedem neuen Architekturentwurf angewendet wird.

Eine solche Checkliste macht Claudes Feedback auch über verschiedene Reviewer und Zeitpunkte hinweg konsistenter, weil nicht bei jeder Session neu improvisiert wird, welche Kriterien überhaupt relevant sind. Gleichzeitig bleibt die Checkliste ein lebendes Dokument, das nach jedem größeren Architekturvorfall, etwa einer teuren Migration wegen eines falschen Schnitts, um die gelernte Lektion ergänzt werden sollte.

9. Grenzen: Was Claude nicht wissen kann

So hilfreich Claude beim Strukturieren und Hinterfragen ist, es kennt weder die tatsächliche Teampolitik noch informelle Machtverhältnisse, noch die geplante Reorganisation, die in drei Monaten die Zuständigkeiten neu verteilt. Ein Architekturvorschlag, der auf dem Papier fachlich sauber ist, kann an genau solchen organisatorischen Realitäten scheitern, die niemand in einen Prompt schreibt, weil sie informell und oft unausgesprochen sind.

Ebenso wenig kennt Claude die tatsächliche Lastverteilung, das reale Wachstum einzelner Fachbereiche oder ungeschriebene Altlasten, die nur im Kopf erfahrener Entwickler existieren. Der Zuschnitt sollte deshalb immer als iterativer Dialog verstanden werden, bei dem Claude Optionen und Gegenargumente liefert, während die endgültige Entscheidung im Team getroffen und mit den Stakeholdern der betroffenen Fachbereiche abgestimmt wird.

10. Zusammenfassung

11. FAQ: Microservices-Schnitt mit Claude: Die wichtigsten Fragen