Das generierte Dokument (in diesem Fall in Asciidoc formatiert) enthält einen formatierten Vertrag. Der Speicherort dieser Datei wäre index/dsl-contract.adoc. Beachten Sie, dass für den Vertrag mit dem Namensfeld die generierte Testmethode validate_should_post_a_user benannt wird. Das Feld, das nicht über das Namensfeld verfügt, wird validate_withList_1. Es entspricht dem Namen der Datei WithList.groovy und dem Index des Vertrags in der Liste. Sie können den Wert der failOnInProgress Spring Cloud Contract-Plugin-Eigenschaft festlegen, um sicherzustellen, dass Ihr Build bricht, wenn mindestens ein ausgeführter Vertrag in Ihren Quellen verbleibt. Wenn Sie die YAML-Vertragsdefinition oder die Java-Definition verwenden, müssen Sie die Handlebars-Notation mit benutzerdefinierten Spring Cloud Contract-Funktionen verwenden, um dies zu erreichen. In diesem Fall können Sie die folgenden Optionen verwenden: Sie können reguläre Ausdrücke verwenden, um Ihre Anforderungen in die Vertrags-DSL zu schreiben. Dies ist besonders nützlich, wenn Sie angeben möchten, dass eine bestimmte Antwort für Anforderungen bereitgestellt werden soll, die einem bestimmten Muster folgen. Außerdem können Sie reguläre Ausdrücke verwenden, wenn Sie Muster und keine genauen Werte sowohl für die Tests als auch für die serverseitigen Tests verwenden müssen. Schließlich sollten wir darauf hinweisen, dass die Gefahr besteht, dass die Zulassung von Verbraucherverträgen, die die Spezifikation eines Dienstanbieters vorantreiben, die konzeptionelle Integrität dieses Anbieters untergraben könnte.

Dienstleistungen kapseln diskrete, identifizierbare, wiederverwendbare Geschäftsfunktionen, deren Integrität nicht durch unangemessene Anforderungen beeinträchtigt werden sollte, die außerhalb ihres Mandats liegen. Leider werden wir mit unserem bestehenden Setup bestehende Verbraucher brechen, wenn wir eine erforderliche Komponente – in diesem Fall das Feld InStock – aus unserem erweiterbaren Schema entfernen. Um den Anbieter zu beheben, müssen wir das gesamte System reparieren: Wenn wir die Funktionalität aus dem Anbieter entfernen und einen neuen Vertrag veröffentlichen, muss jede Consumer-Anwendung mit dem neuen Schema erneut bereitgestellt und die Interaktionen zwischen Diensten gründlich getestet werden. Der ProductSearch-Service kann sich in dieser Hinsicht nicht unabhängig von seinen Verbrauchern entwickeln: Anbieter und Verbraucher müssen alle gleichzeitig springen. Sie können einen Methodenaufruf definieren, der während des Tests auf der Serverseite ausgeführt wird. Eine solche Methode kann der Klasse hinzugefügt werden, die in der Konfiguration als baseClassForTests definiert ist. Der folgende Code zeigt ein Beispiel für den Vertragsteil des Testfalls: Der Stub runner-Kern führt Stubs für Service-Mitarbeiter aus. Wenn Sie Stubs als Dienstleistungsverträge behandeln, können Sie Stub-Runner als Implementierung von verbraucherorientierten Verträgen verwenden.

Das Senden einer Anfrage, wie sie im Anfrageteil des Vertrags dargestellt wird, führt dazu, dass folgende Antwortstelle gesendet wird: In Ihrem Vertrag können Sie sie wie folgt verwenden (Beispiel für Groovy DSL): Verträge ermöglichen die Dienstunabhängigkeit; Paradoxerweise können sie auch Dienstleister und Verbraucher auf unerwünschte Weise koppeln. Ohne die Funktion und Rolle der Verträge, die wir in unserer SOA umsetzen, zu insBlick zu nehmen, unterwerfen wir unsere Dienstleistungen einer Form der “versteckten” Kopplung, die wir selten systematisch angehen können. Das Fehlen programmatischer Einblicke in die Art und Weise, in der eine Dienstleistungsgemeinschaft einen Vertrag angenommen hat, und das Fehlen von Einschränkungen bei den Umsetzungsentscheidungen von Dienstleistungserbringern und Verbrauchern untergraben die angeblichen Vorteile der SOA-Ermöglichung des Unternehmens. Kurz gesagt, das Unternehmen wird mit Dienstleistungen belastet.