FACT COPY · DE
Faktenfassung: Bibliothek für MCP-Architekturmuster
Referenzmuster für lokale, entfernte, hybride und domänenorientierte MCP-Landschaften.
Originalseite: https://travel-mcp.com/de/praxiswissen/architektur-muster/
Sachliche Zusammenfassung
Architekturmuster machen wiederkehrende Systemgrenzen sichtbar, ohne eine einzelne Zielarchitektur als universell darzustellen. Wo müssen Server-, Domänen- und Vertrauensgrenzen liegen, damit Wiederverwendung nicht zu überbreiten Rechten und gekoppelten Ausfällen führt?
Leitfrage und Entscheidungsgrenze
Wo müssen Server-, Domänen- und Vertrauensgrenzen liegen, damit Wiederverwendung nicht zu überbreiten Rechten und gekoppelten Ausfällen führt?
Architekturmuster machen wiederkehrende Systemgrenzen sichtbar, ohne eine einzelne Zielarchitektur als universell darzustellen.
Architektur und Verantwortlichkeiten
Die Grundstruktur besteht aus Host, einer Clientinstanz je Serverbeziehung, domänenorientierten MCP-Servern und den eigentlichen Systems of Record. Ein Travel-Host kann getrennte Clients für Produkt, Offer, Order, Profil und Payment führen. Ein Gateway darf Discovery, Routing und Telemetrie bündeln, aber weder Objektberechtigungen ersetzen noch Tokens ungeprüft an Backends weiterreichen.
Analytische Methode
Servergrenzen werden anhand von Datenverantwortung, Berechtigungsmodell, Releasezyklus, Fehlerdomäne und fachlicher Kohärenz festgelegt. Für jedes Muster werden Datenfluss, Identitäten, Netzwerkpfade, Zustandsort, Timeout, Retry und Kill Switch eingezeichnet. Erst danach werden lokale, Remote- oder hybride Transporte gewählt.
- Host und Client
- Domänenserver
- Gateway und Autorisierung
- Fachsysteme
- Observability und Betrieb
Travel-Fallstudie
Ein Travel-Gateway kann Richtlinien und Discovery bündeln, während getrennte Server für Produkt, Order, Profil und Zahlung ihre Fachrechte behalten.
Das Beispiel gilt erst dann als belastbar, wenn Quellen, Zustände, Rechte und Fehlerpfade genauso konkret dokumentiert sind wie der gewünschte Normalfall.
Typische Fehlkonstruktionen
Ein Universalserver erzeugt riesige Capability-Listen, weitreichende Tokens und einen gemeinsamen Ausfallbereich. Extreme Mikroserver-Zersplitterung zwingt dagegen den Host, fachliche Transaktionen selbst zu koordinieren. Beide Fehler entstehen, wenn technische Endpunkte statt fachlicher Invarianten die Grenze bestimmen.
Erforderliche Evidenz
Ein Architekturmuster ist nur dann nützlich, wenn Einsatzbedingungen, Vorteile, Nachteile und Anti-Pattern dokumentiert sind. Diagramme müssen Autoritäts- und Trust-Boundaries zeigen; reine Boxensammlungen ohne Identitäts- und Datenfluss sind dekorativ, aber fachlich wertlos.
Messgrößen und Abnahmekriterien
Gemessen werden Capability-Auswahlgenauigkeit, Server- und Backendlatenz, Kaskadenfehler, Tokenreichweite, Änderungsfrequenz, unabhängige Deploybarkeit und Wiederherstellungszeit. Architekturqualität ist ein beobachtbares Betriebsmerkmal.
Ergebnis und weiterführende Analyse
Diagramme, Einsatzbedingungen, Vorteile, Nachteile und typische Fehlanwendungen werden je Muster gegenübergestellt.