# REL 3. Wie entwerfen Sie Ihre Workload-Service-Architektur?
Erstellen Sie hoch skalierbare und zuverlässige Workloads mithilfe einer serviceorientierten Architektur (SOA) oder einer Microservices-Architektur. Eine serviceorientierte Architektur (SOA) hat zum Ziel, Softwarekomponenten über Service-Schnittstellen wiederverwendbar zu machen. Die Microservices-Architektur geht noch weiter, um Komponenten kleiner und einfacher zu machen.
**Topics**
+ [REL03-BP01 Segmentierung Ihres Workloads](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Entwickeln von Services, die sich auf bestimmte Geschäftsdomänen und Funktionen konzentrieren](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Bereitstellen von Serviceverträgen pro API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Segmentierung Ihres Workloads
Die Workload-Segmentierung ist wichtig, wenn es um die Festlegung der Resilienzanforderungen Ihrer Anwendung geht. Eine monolithische Architektur sollte vermieden werden, wann immer möglich. Stattdessen sollten Sie sorgfältig überlegen, welche Anwendungskomponenten in Microservices aufgeteilt werden können. Abhängig von den Anforderungen Ihrer Anwendung könnte es sich im Endergebnis um eine Kombination aus einer serviceorientierten Architektur (SOA) und Microservices handeln, wenn dies möglich ist. Workloads, die zustandslos sein können, können eher als Microservices bereitgestellt werden.
**Gewünschtes Ergebnis:** Workloads sollten unterstützbar, skalierbar und so lose miteinander verbunden sein wie möglich.
Wiegen Sie bei Entscheidungen zur Segmentierung von Workloads die Vorteile und die Komplexitäten miteinander ab. Was für ein neues Produkt richtig ist, das gerade auf dem Markt eingeführt wird, unterscheidet sich von den Anforderungen eines Workloads, der von Anfang an skalierbar sein muss. Bei einem Faktorwechsel für einen vorhandenen Monolith müssen Sie berücksichtigen, wie gut dieser aufgeteilt und in zustandslose Anwendungen transformiert werden kann. Die Aufteilung von Services in kleinere Teile ermöglicht kleinen, klar definierten Teams, diese weiterzuentwickeln und zu verwalten. Kleinere Services können jedoch Komplexitäten wie eine möglicherweise erhöhte Latenz, ein komplexeres Debugging und einen erhöhten operativen Aufwand einführen.
**Typische Anti-Muster:**
+ Der [Microservice *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) ist eine Situation, in der die einzelnen Komponenten so stark voneinander abhängig werden, dass der Ausfall einer einzigen Komponente einen wesentlich größeren Ausfall bewirkt. Das bedeutet, dass die Komponenten so starr und anfällig wie ein Monolith sind.
**Vorteile der Einrichtung dieser Best Practice:**
+ Spezifischere Segmente führen zu einer größeren Agilität, zu organisatorischer Flexibilität und zu Skalierbarkeit.
+ Die Auswirkungen von Service-Unterbrechungen werden reduziert.
+ Die einzelnen Komponenten einer Anwendung besitzen möglicherweise unterschiedliche Anforderungen an die Verfügbarkeit, die von einer stärkeren Segmentierung besser unterstützt werden können.
+ Die Verantwortlichkeiten der Teams, die den Workload unterstützen, sind klar definiert.
**Risikostufe bei fehlender Befolgung dieser Best Practice:** Hoch
## Implementierungsleitfaden
Wählen Sie Ihren Architekturtyp basierend auf der Segmentierung Ihres Workloads aus. Wählen Sie eine serviceorientierte Architektur (SOA) oder eine Microservices-Architektur aus. (In seltenen Fällen ist möglicherweise auch eine monolithische Architektur geeignet.) Auch wenn Sie mit einer monolithischen Architektur beginnen möchten, müssen Sie sicherstellen, dass diese modular ist und zu einer SOA oder zu Microservices weiterentwickeln werden kann, wenn Ihr Produkt aufgrund der zunehmenden Einführung durch Benutzer skaliert wird. SOA und Microservices ermöglichen eine kleinteiligere Segmentierung, die als moderne skalierbare und zuverlässige Architektur bevorzugt wird. Es gibt jedoch auch Nachteile, die besonders bei der Bereitstellung einer Microservice-Architektur berücksichtigt werden sollten.
Aufgrund ihrer verteilten Computing-Architektur kann es schwieriger sein, die Latenzanforderungen von Benutzern zu erfüllen. Außerdem sind das Debugging und die Nachverfolgung von Benutzerinteraktionen komplexer. Zur Lösung dieses Problems können Sie AWS X-Ray verwenden. Ein weiterer Effekt ist die erhöhte operative Komplexität, da die Anzahl der von Ihnen verwalteten Anwendungen zunimmt. In der Folge müssen Sie eine größere Zahl voneinander unabhängiger Komponenten bereitstellen.
![\[Diagramm mit einem Vergleich von monolithischen, serviceorientierten und Microservice-Architekturen\]](http://docs.aws.amazon.com/de_de/wellarchitected/2023-10-03/framework/images/monolith-soa-microservices-comparison.png)
## Implementierungsschritte
+ Ermitteln Sie die richtige Architektur für den Faktorwechsel oder die Entwicklung Ihrer Anwendung. SOA und Microservices bieten eine jeweils kleinere Segmentierung, die als moderne skalierbare und zuverlässige Architektur bevorzugt wird. SOA kann ein guter Kompromiss für das Erreichen einer kleineren Segmentierung sein, während die Komplexität von Microservices zum Teil vermieden wird. Weitere Informationen finden Sie in [Kompromisse bei Microservices](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Wenn Ihre Workload für sie zugänglich ist und Ihre Organisation sie unterstützen kann, sollten Sie eine Microservices-Architektur verwenden, um die beste Agilität und Zuverlässigkeit zu erzielen. Weitere Informationen finden Sie in [Implementieren von Microservices in AWS.](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Sie sollten das Muster mit der Bezeichnung [*Strangler Fig* („Würgefeige“) verwenden,](https://martinfowler.com/bliki/StranglerFigApplication.html) um einen Faktorwechsel für einen Monolithen durchzuführen, bei dem Sie diesen in kleinere Komponenten aufteilen. Dies umfasst die schrittweise Ersetzung spezifischer Anwendungskomponenten durch neue Anwendungen und Services. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) dient als Ausgangspunkt für den inkrementellen Faktorwechsel. Weitere Informationen finden Sie in [Nahtlose Integration ältere On-Premises-Workloads unter Anwendung eines Strangler-Fig-Musters](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ Die Implementierung von Microservices erfordert möglicherweise einen Mechanismus für die Entdeckung von Services, damit diese verteilten Services miteinander kommunizieren können. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) kann mit serviceorientierten Architekturen verwendet werden, um eine zuverlässige Erkennung von Services und den Zugriff auf sie zu unterstützen. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) kann für die dynamische, DNS-basierte Serviceerkennung verwendet werden.
+ Wenn Sie von einem Monolithen zur SOA migrieren, kann [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) helfen, als Service-Bus die Lücke zu überbrücken, wenn Sie ältere Anwendungen in der Cloud neu entwerfen.
+ Im Fall vorhandener Monolithen mit einer einzigen, geteilten Datenbank müssen Sie entscheiden, wie Sie die Daten neu in kleineren Segmenten organisieren. Dabei kann es sich um Geschäftsbereiche, Zugriffsmuster oder Datenstrukturen handeln. An diesem Punkt des Faktorwechsel-Prozesses sollten Sie entscheiden, ob Sie eine relationale oder eine nicht relationale (NoSQL) Datenbank verwenden. Weitere Informationen finden Sie in [Von SQL zu NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Aufwand für den Implementierungsplan:** Hoch
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL03-BP02 Entwickeln von Services, die sich auf bestimmte Geschäftsdomänen und Funktionen konzentrieren](rel_service_architecture_business_domains.md)
**Zugehörige Dokumente:**
+ [Amazon API Gateway: Konfigurieren einer REST-API mit OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Was ist eine serviceorientierte Architektur?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Bounded Context (Begrenzter Kontext) (ein zentrales Muster im domänengesteuerten Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementieren von Microservices in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Kompromisse bei Microservices](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices – eine Definition dieses neuen Architekturbegriffs](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices in AWS](https://aws.amazon.com/microservices/)
+ [Was ist AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Zugehörige Beispiele:**
+ [Workshop für die iterative App-Modernisierung](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Zugehörige Videos:**
+ [Kompetenz mit Microservices in AWS](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Entwickeln von Services, die sich auf bestimmte Geschäftsdomänen und Funktionen konzentrieren
Eine serviceorientierte Architektur (SOA) definiert Services mit genau abgegrenzten Funktionen, die von Geschäftsanforderungen definiert werden. Microservices verwenden Domänenmodelle und begrenzten Kontext, um Servicegrenzen entlang der Grenzen des Geschäftskontextes zu ziehen. Die Konzentration auf Geschäftsdomänen und Funktionen hilft Teams dabei, unabhängige Zuverlässigkeitsanforderungen für ihre Services zu definieren. Begrenzte Kontexte isolieren und kapseln die Geschäftslogik, sodass Teams besser überlegen können, wie mit Fehlern umzugehen ist.
**Gewünschtes Ergebnis:** Ingenieure und geschäftliche Interessenvertreter definieren gemeinsam begrenzte Kontexte und verwenden sie, um Systeme als Services zu entwerfen, die bestimmte Geschäftsfunktionen erfüllen. Diese Teams verwenden etablierte Praktiken wie Event Storming, um Anforderungen zu definieren. Neue Anwendungen sind als Services mit klar definierten Grenzen und losen Verkopplungen definiert. Bestehende Monolithe werden in [begrenzte Kontexte](https://martinfowler.com/bliki/BoundedContext.html) zerlegt und Systemdesigns bewegen sich in Richtung SOA- oder Microservice-Architekturen. Bei der Refaktorisierung von Monolithen kommen etablierte Ansätze wie Bubble-Kontexte und Monolith-Zerlegung zur Anwendung.
Domänenorientierte Services werden als ein oder mehrere Prozesse ausgeführt, die keinen gemeinsamen Zustand haben. Sie reagieren selbstständig auf Nachfrageschwankungen und behandeln Störszenarien anhand domänenspezifischer Anforderungen.
**Typische Anti-Muster:**
+ Teams werden für bestimmte technische Bereiche wie UI und UX, Middleware oder Datenbank gebildet, anstatt für bestimmte Geschäftsdomänen.
+ Anwendungen erstrecken sich über die Zuständigkeiten der einzelnen Bereiche. Services, die sich über begrenzte Kontexte erstrecken, können schwieriger zu verwalten sein, erfordern einen größeren Testaufwand und erfordern die Teilnahme mehrerer Domänenteams an Softwareupdates.
+ Domänenabhängigkeiten wie Domain-Entity-Bibliotheken werden von allen Services gemeinsam genutzt, sodass Änderungen für eine Servicedomäne Änderungen an anderen Service-Domains erfordern.
+ Serviceverträge und Geschäftslogik formulieren Entities nicht in einer gemeinsamen und konsistenten Domänensprache, was zu Übersetzungsebenen führt, die Systeme komplizieren und den Debugging-Aufwand erhöhen.
**Vorteile der Nutzung dieser bewährten Methode:** Anwendungen sind als unabhängige Services konzipiert, die durch Geschäftsdomänen begrenzt sind und eine gemeinsame Geschäftssprache verwenden. Services sind unabhängig voneinander testbar und einsetzbar. Services erfüllen die domänenspezifischen Resilienzanforderungen für die implementierte Domäne.
**Risikostufe bei fehlender Befolgung dieser Best Practice:** Hoch
## Implementierungsleitfaden
Domain-driven Decision (DDD, Domänengesteuerte Entscheidung) ist der grundlegende Ansatz für das Entwerfen und Entwickeln von Software rund um Geschäftsdomänen. Bei der Entwicklung von Services, die sich auf Geschäftsdomänen konzentrieren, ist es hilfreich, mit einem vorhandenen Framework zu arbeiten. Wenn Sie mit bestehenden monolithischen Anwendungen arbeiten, können Sie die Vorteile von Zerlegungsmustern nutzen, die etablierte Techniken zur Modernisierung von Anwendungen in Services bereitstellen.
![\[Flussdiagramm, das den Ansatz der domänengesteuerten Entscheidung darstellt\]](http://docs.aws.amazon.com/de_de/wellarchitected/2023-10-03/framework/images/domain-driven-decision.png)
## Implementierungsschritte
+ Teams können [Event-Storming-Workshops](https://serverlessland.com/event-driven-architecture/visuals/event-storming) veranstalten, um rasch Ereignisse, Befehle, Mengen und Domänen in einem unkomplizierten Notizformat zu sammeln.
+ Sobald Domain-Entities und -Funktionen in einem Domänenkontext gebildet wurden, können Sie Ihre Domäne mithilfe eines [begrenzten Kontexts](https://martinfowler.com/bliki/BoundedContext.html)weiter in kleinere Modelle unterteilt, wobei Entities mit ähnlichen Funktionen und Attributen in Gruppen sortiert werden. Wenn das Modell in Kontexte unterteilt ist, entsteht eine Vorlage für die Begrenzung von Microservices.
+ Für die Website Amazon.com können Entities beispielsweise Pakete, Zustellung, Zeitplan, Preise, Rabatte und Währung enthalten.
+ Paket, Zustellung und Zeitplan werden dem Versandkontext zugeordnet, während Preis, Rabatt und Währung dem Preiskontext zugeordnet sind.
+ [Zerlegung von Monolithen in Microservices](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) skizziert Muster für das Refactoring von Microservices. Die Verwendung von Mustern für die Unterteilung nach Geschäftsfähigkeit, Subdomäne oder Transaktion passt gut zu domänengesteuerten Ansätzen.
+ Taktische Techniken wie der [Bubble-Kontext](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) ermöglichen es Ihnen, DDD in bestehenden oder älteren Anwendungen einzuführen, ohne dass Sie im Voraus Änderungen vornehmen und sich voll und ganz auf DDD verlassen müssen. Bei einem Bubble-Kontext-Ansatz wird mithilfe von Service-Mapping und -koordination ein kleiner begrenzter Kontext oder eine [Ebene zur Korruptionsbekämpfung](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)erstellt, die das neu definierte Domänenmodell vor äußeren Einflüssen schützt.
Nachdem die Teams eine Domänenanalyse durchgeführt und Entities und Serviceverträge definiert haben, können sie AWS-Services nutzen, um ihr domänengesteuertes Design als Cloud-basierte Services zu implementieren.
+ Beginnen Sie Ihre Entwicklung, indem Sie Tests definieren, die die Geschäftsregeln Ihrer Domäne anwenden. Test-driven Development (TDD, Testgetriebene Entwicklung) und Behavior-driven Development (BDD, verhaltensgetriebene Entwicklung) helfen Teams dabei, die Services auf die Lösung von Geschäftsproblemen zu konzentrieren.
+ Wählen Sie die [AWS-Services,](https://aws.amazon.com/microservices/) die den Anforderungen Ihrer Geschäftsdomänen und Ihrer [Microservice-Architektur](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)am besten entsprechen:
+ [AWS Serverless](https://aws.amazon.com/serverless/) ermöglicht es Ihrem Team, sich auf eine bestimmte Domänenlogik zu konzentrieren, anstatt Server und Infrastruktur zu verwalten.
+ [Container in AWS](https://aws.amazon.com/containers/) vereinfachen die Verwaltung Ihrer Infrastruktur, sodass Sie sich auf Ihre Domänenanforderungen konzentrieren können.
+ [Speziell entwickelte Datenbanken](https://aws.amazon.com/products/databases/) helfen Ihnen dabei, Ihre Domänenanforderungen dem am besten geeigneten Datenbanktyp zuzuordnen.
+ [Hexagonale Architekturen auf AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) skizzieren ein Framework zur Integration von Geschäftslogik in Services. Dabei wird rückwärts von der Geschäftsdomäne aus gearbeitet, um funktionale Anforderungen zu erfüllen und dann Integrationsadapter zu implementieren. Muster, die Schnittstellendetails von der Geschäftslogik mit AWS-Services trennen, helfen Teams, sich auf die Funktionalität der Domäne zu konzentrieren und die Softwarequalität zu verbessern.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL03-BP01 Segmentierung Ihres Workloads](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP03 Bereitstellen von Serviceverträgen pro API](rel_service_architecture_api_contracts.md)
**Zugehörige Dokumente:**
+ [AWS Microservices](https://aws.amazon.com/microservices/)
+ [Implementieren von Microservices in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [How to break a Monolith into Microservices (Aufschlüsseln eines Monolithen in Microservices)](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Getting Started with DDD when Surrounded by Legacy Systems (Erste Schritte mit DDD, wenn die Umgebung aus Legacy-Systemen besteht)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [ Domain-Driven Design: Tackling Complexity in the Heart of Software (Domänengesteuertes Design: Umgang mit der Komplexität im Herzen der Software) ](https://www.amazon.com/gp/product/0321125215)
+ [ Hexagonale Architekturen auf AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)
+ [ Zerlegung von Monolithen in Microservices ](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html)
+ [ Event Storming ](https://serverlessland.com/event-driven-architecture/visuals/event-storming)
+ [ Nachrichten zwischen begrenzten Kontexten ](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)
+ [ Microservices ](https://www.martinfowler.com/articles/microservices.html)
+ [ Testgetriebene Entwicklung ](https://en.wikipedia.org/wiki/Test-driven_development)
+ [ Verhaltensgetriebene Entwicklung ](https://en.wikipedia.org/wiki/Behavior-driven_development)
**Zugehörige Beispiele:**
+ [ Workshop „Enterprise Cloud Native“ ](https://catalog.us-east-1.prod.workshops.aws/workshops/0466c70e-4216-4352-98d9-5a8af59c86b2/en-US)
+ [ Designing Cloud Native Microservices on AWS (from DDD/EventStormingWorkshop) (Entwerfen Cloud-nativer Microservices in AWS (aus DDD/EventStormingWorkshop)) ](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main)
**Zugehörige Tools:**
+ [AWS Cloud-Datenbanken ](https://aws.amazon.com/products/databases/)
+ [ Serverless auf AWS](https://aws.amazon.com/serverless/)
+ [ Container in AWS](https://aws.amazon.com/containers/)
# REL03-BP03 Bereitstellen von Serviceverträgen pro API
Serviceverträge sind dokumentierte Vereinbarungen zwischen API-Herstellern und Verbrauchern, die in einer maschinenlesbaren API-Definition festgehalten sind. Eine Vertragsversionsverwaltungsstrategie ermöglicht es Verbrauchern, die vorhandene API weiter zu verwenden und ihre Anwendungen auf eine neuere API zu migrieren, wenn sie bereit sind. Die Bereitstellung durch den Produzenten kann jederzeit erfolgen, solange der Vertrag eingehalten wird. Die Serviceteams können den Technologie-Stack ihrer Wahl verwenden, um den API-Vertrag zu erfüllen.
**Gewünschtes Ergebnis:**
**Typische Anti-Muster:** Anwendungen, die mit serviceorientierten Architekturen oder Microservice-Architekturen erstellt wurden, können unabhängig voneinander arbeiten und verfügen gleichzeitig über eine integrierte Laufzeitabhängigkeit. Änderungen, die für einen API-Verbraucher oder -Hersteller bereitgestellt werden, beeinträchtigen die Stabilität des Gesamtsystems nicht, wenn beide Seiten einen gemeinsamen API-Vertrag einhalten. Komponenten, die über Service-APIs kommunizieren, können unabhängige funktionale Releases, Upgrades von Laufzeitabhängigkeiten oder ein Failover auf eine Notfallwiederherstellung (DR) ausführen, ohne dass sich dies gegenseitig beeinträchtigt. Darüber hinaus können spezialisierte Services unabhängig voneinander skaliert werden und können dabei den Ressourcenbedarf absorbieren, ohne dass andere Services ebenfalls skaliert werden müssen.
+ Erstellung von Service-APIs ohne stark typisierte Schemata. Dies führt zu APIs, die nicht zum Generieren von API-Bindungen und Payloads verwendet werden können, die nicht programmgesteuert validiert werden können.
+ Keine Versionsverwaltungsstrategie, weshalb API-Verbraucher dazu gezwungen sind, Updates zu installieren, Releases einzuspielen oder eine Notfallwiederherstellung durchzuführen, wenn sich Serviceverträge weiterentwickeln.
+ Fehlermeldungen, die Details der zugrundeliegenden Service-Implementierung preisgeben, anstatt Integrationsfehler im Kontext und in der Sprache der Domäne zu beschreiben.
+ Keine Verwendung von API-Verträgen zur Entwicklung von Testfällen und zur Simulation von API-Implementierungen, um unabhängige Tests von Servicekomponenten zu ermöglichen.
**Vorteile der Nutzung dieser bewährten Methode:** Verteilte Systeme, die aus Komponenten bestehen, die über API-Serviceverträge kommunizieren, können die Zuverlässigkeit verbessern. Entwickler können potenzielle Probleme schon früh im Entwicklungsprozess erkennen, indem sie während der Kompilierung eine Typprüfung durchführen, um sicherzustellen, dass Anfragen und Antworten dem API-Vertrag entsprechen und die erforderlichen Felder vorhanden sind. API-Verträge bieten eine übersichtliche, selbstdokumentierende Schnittstelle für APIs und sorgen für eine bessere Interoperabilität zwischen verschiedenen Systemen und Programmiersprachen.
**Risikostufe bei fehlender Befolgung dieser Best Practice:** Mittel
## Implementierungsleitfaden
Sobald Sie Geschäftsbereiche identifiziert und Ihre Workload-Segmentierung festgelegt haben, können Sie Ihre Service-APIs entwickeln. Definieren Sie zunächst maschinenlesbare Serviceverträge für APIs und implementieren Sie dann eine Strategie zur API-Versionsverwaltung. Wenn Sie bereit sind, Services über gängige Protokolle wie REST, GraphQL oder asynchrone Ereignisse zu implementieren, können Sie AWS-Services in Ihre Architektur einbinden, um Ihre Komponenten mit stark typisierten API-Verträgen zu integrieren.
**AWS-Services für API-Serviceverträge**
Implementieren Sie AWS-Services wie [Amazon API Gateway](https://aws.amazon.com/api-gateway/), [AWS AppSync](https://aws.amazon.com/appsync/)und [Amazon EventBridge](https://aws.amazon.com/eventbridge/) in Ihre Architektur, um API-Serviceverträge in Ihrer Anwendung zu verwenden. Amazon API Gateway hilft Ihnen bei der direkten Integration in native AWS-Services und andere Webservices. API Gateway unterstützt die [OpenAPI-Spezifikation](https://github.com/OAI/OpenAPI-Specification) sowie die Versionsverwaltung. AWS AppSync ist ein verwalteter [GraphQL](https://graphql.org/) -Endpunkt, den Sie konfigurieren, indem Sie ein GraphQL-Schema definieren, um eine Serviceschnittstelle für Abfragen, Mutationen und Abonnements festzulegen. Amazon EventBridge verwendet Ereignisschemata, um Ereignisse zu definieren und Codebindungen für Ihre Ereignisse zu generieren.
## Implementierungsschritte
+ Definieren Sie zunächst einen Vertrag für Ihre API. In einem Vertrag werden die Funktionen einer API festgehalten und stark typisierte Datenobjekte und Felder für die API-Eingabe und -Ausgabe definiert.
+ Wenn Sie APIs in API Gateway konfigurieren, können Sie OpenAPI-Spezifikationen für Ihre Endpunkte importieren und exportieren.
+ [Eine OpenAPI-Definition zu importieren,](https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html) vereinfacht die Erstellung Ihrer API und kann in AWS-Infrastrukturen wie [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/) und [AWS Cloud Development Kit (AWS CDK) integriert werden](https://aws.amazon.com/cdk/).
+ [Eine API-Definition zu exportieren,](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) vereinfacht die Integration in API-Testtools und bietet Servicekunden eine Integrationsspezifikation.
+ Definieren und verwalten Sie GraphQL-APIs mit AWS AppSync, indem Sie [eine GraphQL-Schema-](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) Datei definieren, um Ihre Vertragsschnittstelle zu generieren und die Interaktion mit komplexen REST-Modellen, mehreren Datenbanktabellen oder Legacy-Services zu vereinfachen.
+ [AWS Amplify](https://aws.amazon.com/amplify/) -Projekte, die in AWS AppSync integriert sind, generieren stark typisierte JavaScript-Abfragedateien, die Sie sowohl in Ihrer Anwendung als auch in einer AWS AppSync-GraphQL-Client-Bibliothek für [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) -Tabellen verwenden können.
+ Wenn Sie Serviceereignisse aus Amazon EventBridge verarbeiten, befolgen diese Ereignisse Schemata, die bereits in der Schemaregistrierung existieren oder die Sie mit der OpenAPI-Spezifikation definieren. Mit einem in der Registrierung definierten Schema können Sie auch Client-Bindungen aus dem Schemavertrag generieren, um Ihren Code in Ereignisse zu integrieren.
+ API erweitern oder versionieren Die Erweiterung einer API ist eine einfachere Option, wenn Felder hinzugefügt werden, die mit optionalen Feldern oder Standardwerten für Pflichtfelder konfiguriert werden können.
+ JSON-basierte Verträge für Protokolle wie REST und GraphQL können sich gut für eine Vertragserweiterung eignen.
+ XML-basierte Verträge für Protokolle wie SOAP sollten mit Service-Verbrauchern getestet werden, um festzustellen, ob eine Vertragserweiterung durchführbar ist.
+ Erwägen Sie bei der Versionsverwaltung einer API die Implementierung einer Proxy-Versionsverwaltung, bei der eine Fassade zur Unterstützung von Versionen verwendet wird, sodass die Logik in einer einzigen Codebasis verwaltet werden kann.
+ Mit API Gateway können Sie [Anfrage- und von Antwortzuordnungen](https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#transforming-request-response-body) nutzen, um Vertragsänderungen einfacher zu übernehmen. Hierzu wird eine Fassade eingerichtet, die Standardwerte für neue Felder bereitstellt oder entfernte Felder aus einer Anfrage oder Antwort herausnimmt. Mit diesem Ansatz kann der zugrunde liegende Service mit einer einzelnen Codebasis betrieben werden.
## Ressourcen
**Zugehörige bewährte Methoden:**
+ [REL03-BP01 Segmentierung Ihres Workloads](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Entwickeln von Services, die sich auf bestimmte Geschäftsdomänen und Funktionen konzentrieren](rel_service_architecture_business_domains.md)
+ [REL04-BP02 Implementieren lose gekoppelter Abhängigkeiten](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP03 Steuern und Einschränken von Wiederholungsaufrufen](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP05 Festlegen von Client-Zeitüberschreitungen](rel_mitigate_interaction_failure_client_timeouts.md)
**Zugehörige Dokumente:**
+ [ Was ist eine API (Anwendungsprogrammierschnittstelle)? ](https://aws.amazon.com/what-is/api/)
+ [ Implementieren von Microservices in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ Kompromisse bei Microservices ](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [ Microservices – eine Definition dieses neuen Architekturbegriffs ](https://www.martinfowler.com/articles/microservices.html)
+ [ Microservices in AWS](https://aws.amazon.com/microservices/)
+ [ Arbeiten mit API Gateway-Erweiterungen für OpenAPI ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions.html)
+ [ OpenAPI-Spezifikation ](https://github.com/OAI/OpenAPI-Specification)
+ [ GraphQL: Schemata und Typen ](https:/graphql.org/learn/schema)
+ [ Amazon EventBridge-Codebindungen ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-code-bindings.html)
**Zugehörige Beispiele:**
+ [ Amazon API Gateway: Konfigurieren einer REST-API mit OpenAPI ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [ Amazon API Gateway zu Amazon DynamoDB CRUD-Anwendung mit OpenAPI ](https://serverlessland.com/patterns/apigw-ddb-openapi-crud?ref=search)
+ [ Moderne Anwendungsintegrationsmuster in einem serverlosen Zeitalter: API Gateway-Serviceintegration ](https://catalog.us-east-1.prod.workshops.aws/workshops/be7e1ee7-b91f-493d-93b0-8f7c5b002479/en-US/labs/asynchronous-request-response-poll/api-gateway-service-integration)
+ [ Implementieren einer Header-basierten API Gateway-Versionsverwaltung mit Amazon CloudFront ](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/)
+ [AWS AppSync: Erstellen einer Client-Anwendung ](https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app.html#aws-appsync-building-a-client-app)
**Zugehörige Videos:**
+ [ Verwenden von OpenAPI in AWS SAM zur Verwaltung von API Gateway ](https://www.youtube.com/watch?v=fet3bh0QA80)
**Zugehörige Tools:**
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)