# Conception de l’architecture de votre service de charge de travail
Créez des charges de travail hautement évolutives et fiables à l’aide d’une architecture orientée service (SOA) ou d’une architecture de microservices. L’architecture orientée services (SOA) consiste à rendre les composants logiciels réutilisables via les interfaces de service. L’architecture des microservices va plus loin, en particulier en rendant les composants plus petits et plus simples.
Les interfaces d’architecture orientée service (SOA) utilisent des normes de communication communes permettant leur intégration rapide à de nouvelles charges de travail. La SOA a remplacé la pratique consistant à créer des architectures monolithes, composées d’unités interdépendantes et indivisibles.
Chez AWS, nous avons toujours utilisé la SOA. Nous concevons toutefois désormais nos systèmes à l’aide de microservices. Bien que les micro-services présentent plusieurs qualités attractives, l’avantage le plus important pour la disponibilité est le fait que les microservices sont plus légers et plus simples. Ils vous permettent de différencier la disponibilité requise par les différents services, et ainsi de concentrer plus spécifiquement vos investissements sur les microservices qui présentent les besoins les plus importants en disponibilité. Par exemple, pour fournir des pages d’informations produits sur Amazon.com (« pages de détails »), des centaines de microservices sont appelés pour construire des parties distinctes de la page. Tandis que certains services doivent être disponibles pour fournir le prix et les détails des produits, la grande majorité du contenu de la page peut simplement être exclu si le service n’est pas disponible. Même des éléments tels que les photos et commentaires ne sont pas requis pour fournir une expérience permettant à un client d’acheter un produit.
**Topics**
+ [REL03-BP01 Choisissez comment segmenter votre charge de travail](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Créer des services axés sur des domaines d’activité et la fonctionnalité](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Fournir des contrats de service par API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Choisissez comment segmenter votre charge de travail
La segmentation de la charge de travail est importante lorsqu’il s’agit de déterminer les exigences de résilience de votre application. L’architecture monolithique doit être évitée dans la mesure du possible. À la place, réfléchissez bien aux composants de l’application capables d’être divisés en microservices. Selon les exigences de votre application, il peut s'agir d'une combinaison d'une architecture orientée services (SOA) avec des microservices dans la mesure du possible. Les charges de travail capables d’absence d’état sont davantage en mesure d’être déployées en tant que microservices.
**Résultat désiré :** les charges de travail doivent être supportables, évolutives et aussi faiblement couplées que possible.
Lorsque vous choisissez comment segmenter votre charge de travail, comparez les avantages aux complexités. Ce qui convient pour un nouveau produit en course pour un premier lancement est différent de ce dont a besoin une charge de travail conçue pour augmenter d’échelle. Lors de la refactorisation d’une architecture monolithique existante, vous devez évaluer comment l’application prendra en charge une décomposition vers l’absence d’état. La division de services en microservices permet aux petites équipes bien définies de les développer et les gérer. Toutefois, les services plus petits peuvent créer des complexités, dont une latence supérieure, un débogage plus complexe et une charge opérationnelle accrue.
**Anti-modèles courants :**
+ Le [microservice *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) est une situation dans laquelle les composants atomiques deviennent si interdépendants que l’échec de l’un d’entre eux résulte en un échec encore plus important, ce qui rend les composants aussi rigides et fragiles qu’une architecture monolithique.
**Avantages liés au respect de cette pratique :**
+ L’utilisation de segments plus petits permet une plus grande agilité, une plus grande flexibilité organisationnelle et une capacité de mise à l’échelle.
+ L’impact réduit des interruptions de service.
+ Les composants de l’application peuvent avoir différentes exigences de disponibilité, pouvant être pris en charge par une segmentation plus atomique.
+ Des responsabilités bien définies pour les équipes prenant en charge la charge de travail.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
Choisissez votre type d’architecture en fonction de la façon dont vous segmenterez votre charge de travail. Choisissez une architecture SOA ou une architecture de microservices (ou dans de rares cas, une architecture monolithique). Même si vous choisissez de commencer par une architecture monolithe, vous devez vous assurer qu'elle est modulaire et qu'elle puisse finalement évoluer vers des microservices au fur et à SOA mesure que votre produit évolue avec l'adoption par les utilisateurs. SOAet les microservices offrent respectivement une segmentation plus petite, ce qui est préférable en tant qu'architecture moderne, évolutive et fiable, mais certains compromis doivent être pris en compte, en particulier lors du déploiement d'une architecture de microservices.
Le principal compromis est que vous avez maintenant une architecture pour le calcul distribué qui peut compliquer le respect des exigences en matière de latence des utilisateurs et qui complexifie le suivi et le débogage des interactions des utilisateurs. AWS X-Ray peut vous aider à résoudre ce problème. Un autre effet à prendre en compte est la hausse de la complexité opérationnelle à mesure que vous augmentez le nombre d’applications que vous gérez, ce qui nécessite le déploiement de plusieurs composants indépendants.
![\[Schéma comparant les architectures monolithique, orientée services et de microservices\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/reliability-pillar/images/monolith-soa-microservices-comparison.png)
## Étapes d’implémentation
+ Déterminer l’architecture adaptée pour refactoriser ou créer votre application. SOAet les microservices offrent respectivement une segmentation plus petite, ce qui est préférable en tant qu'architecture moderne, évolutive et fiable. SOApeut être un bon compromis pour réduire la segmentation tout en évitant certaines des complexités des microservices. Pour plus de détails, consultez la section [Compromis des microservices](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Si votre charge de travail est appropriée et que votre organisation peut la prendre en charge, vous devez utiliser une architecture de microservices pour obtenir la meilleure agilité et la meilleure fiabilité. Pour plus de détails, voir [Implémentation de microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html).
+ Envisagez de suivre le [modèle *Strangler Fig*](https://martinfowler.com/bliki/StranglerFigApplication.html) pour refactoriser un monolithe en composants plus petits. Cela implique le remplacement progressif de composants spécifiques de l’application par de nouvelles applications et de nouveaux services. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) sert de point de départ à la refactorisation incrémentielle. Pour plus de détails, consulter [Migrer sans interruption vers des charges de travail existantes sur site à l’aide d’un modèle Figuier étrangleur](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ La mise en œuvre de microservices peut nécessiter un mécanisme de découverte de services pour permettre à ces services distribués de communiquer entre eux. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)peut être utilisé avec des architectures orientées services pour permettre une découverte et un accès fiables aux services. [AWS Cloud Map](https://aws.amazon.com/cloud-map/)peut également être utilisé pour la découverte de services dynamique DNS basée sur des données.
+ Si vous passez d'un monolithe à un bus de service, [Amazon SOA MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) peut vous aider à combler cette lacune lors de la refonte d'applications existantes dans le cloud.
+ Pour les architectures monolithiques existantes avec une base de données partagée unique, choisissez comment réorganiser les données en segments plus petits. Vous pouvez les réorganiser par unité commerciale, modèle d’accès ou structure de données. À ce stade du processus de refactorisation, vous devez choisir de passer à un type de base de données relationnel ou non relationnel (nonSQL). Pour plus de détails, voir [De SQL à Non SQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Niveau d’effort du plan d’implémentation :** élevé
## Ressources
**Bonnes pratiques associées :**
+ [REL03-BP02 Créer des services axés sur des domaines d’activité et la fonctionnalité](rel_service_architecture_business_domains.md)
**Documents connexes :**
+ [Amazon API Gateway : Configuration d'une application à REST API l'aide d'Open API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Qu’est-ce que l’architecture orientée service ?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Contexte délimité (modèle central dans la conception pilotée par domaine)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implémentation de microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Compromis des microservices](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices : une définition de ce nouveau terme architectural](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices sur AWS](https://aws.amazon.com/microservices/)
+ [Qu'est-ce que c'est AWS App Mesh ?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Exemples connexes :**
+ [Atelier sur la modernisation itérative des applications](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Vidéos connexes :**
+ [Garantir l'excellence grâce aux microservices sur AWS](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Créer des services axés sur des domaines d’activité et la fonctionnalité
Une architecture orientée services (SOA) définit des services avec des fonctions bien déterminées dictées par les besoins métier. Les microservices utilisent des modèles de domaine et un contexte limité pour définir les limites des services en fonction des limites du contexte métier. En se concentrant sur les domaines d’activité et les fonctionnalités, les équipes peuvent définir des exigences de fiabilité indépendantes pour leurs services. Les contextes limités isolent et encapsulent la logique métier, ce qui permet aux équipes de mieux raisonner sur la manière de gérer les défaillances.
**Résultat escompté :** les ingénieurs et les parties prenantes de l’entreprise définissent conjointement des contextes délimités et les utilisent pour concevoir des systèmes en tant que services remplissant des fonctions commerciales spécifiques. Ces équipes utilisent des pratiques établies telles que l’event storming pour définir les exigences. Les nouvelles applications sont conçues comme des services dont les limites sont bien définies et qui possèdent un couplage faible. Les monolithes existants sont décomposés en [contextes délimités](https://martinfowler.com/bliki/BoundedContext.html) et les conceptions des systèmes évoluent vers des architectures SOA ou de microservices. Lorsque les monolithes sont refactorisés, des approches établies telles que les contextes de bulles et les modèles de décomposition des monolithes sont appliquées.
Les services orientés domaine sont exécutés sous la forme d’un ou de plusieurs processus qui ne partagent pas d’état. Ils répondent de manière indépendante aux fluctuations de la demande et gèrent les scénarios de panne à la lumière des exigences spécifiques du domaine.
**Anti-modèles courants :**
+ Les équipes sont constituées autour de domaines techniques spécifiques tels que l’interface utilisateur et l’expérience utilisateur, les intergiciels ou les bases de données plutôt que de domaines commerciaux spécifiques.
+ Les applications couvrent des responsabilités de domaine. Les services qui couvrent des contextes limités peuvent être plus difficiles à gérer, nécessiter des efforts de test plus importants et nécessiter la participation de plusieurs équipes de domaine aux mises à jour logicielles.
+ Les dépendances de domaine, telles que les bibliothèques d’entités de domaine, sont partagées entre les services de telle sorte que les modifications apportées à un domaine de service nécessitent des modifications apportées à d’autres domaines de service.
+ Les contrats de service et la logique métier n’expriment pas les entités dans un langage de domaine commun et cohérent, ce qui crée des couches de traduction qui compliquent les systèmes et augmentent les efforts de débogage.
**Avantages du respect de cette bonne pratique :** les applications sont conçues comme des services indépendants délimités par domaines d’activité et utilisent un langage métier commun. Les services peuvent être testés et déployés indépendamment. Les services répondent aux exigences de résilience spécifiques au domaine mis en œuvre.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** élevé
## Directives d’implémentation
La conception pilotée par domaine (DDD) est l’approche fondamentale de la conception et de la création de logiciels autour de domaines métier. Il est utile de travailler avec un cadre existant lorsque vous créez des services axés sur des domaines métier. Lorsque vous travaillez avec des applications monolithiques existantes, vous pouvez tirer parti des modèles de décomposition qui fournissent des techniques éprouvées pour moderniser les applications en services.
![\[Organigramme illustrant l’approche de la conception pilotée par domaine.\]](http://docs.aws.amazon.com/fr_fr/wellarchitected/latest/reliability-pillar/images/domain-driven-decision.png)
## Étapes d’implémentation
+ Les équipes peuvent organiser des ateliers [event storming](https://serverlessland.com/event-driven-architecture/visuals/event-storming) pour identifier rapidement les événements, les commandes, les agrégats et les domaines dans un format léger de notes autocollantes.
+ Une fois que les entités et les fonctions de domaine ont été formées dans un contexte de domaine, vous pouvez diviser votre domaine en services à l’aide d’un [contexte délimité](https://martinfowler.com/bliki/BoundedContext.html), dans lequel les entités partageant des caractéristiques et des attributs similaires sont regroupées. La division en contextes permet de faire émerger un modèle de délimitation des microservices.
+ Par exemple, les entités du site Web Amazon.com peuvent inclure le colis, la livraison, le calendrier, le prix, la remise et la devise.
+ Le colis, la livraison et le calendrier sont regroupés dans le contexte d’expédition, tandis que le prix, la remise et la devise sont regroupés dans le contexte de tarification.
+ [Décomposition des monolithes en microservices](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) décrit les modèles de refactorisation des microservices. L’utilisation de modèles de décomposition par capacité métier, sous-domaine ou transaction s’inscrit parfaitement dans les approches axées sur le domaine.
+ Les techniques tactiques telles que le [contexte à bulles](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) vous permettent d’introduire le DDD dans des applications existantes ou héritées sans devoir procéder à des réécritures préalables et sans engagement total envers le DDD. Dans une approche basée sur un contexte à bulles, un petit contexte délimité est établi à l’aide d’une cartographie et d’une coordination des services, ou [couche anticorruption](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context), qui protège le modèle de domaine nouvellement défini des influences extérieures.
Une fois que les équipes ont effectué une analyse du domaine et défini des entités et des contrats de service, elles peuvent tirer parti des services AWS pour mettre en œuvre leur conception axée sur le domaine sous forme de services basés sur le cloud.
+ Commencez votre développement en définissant des tests qui appliquent les règles métier de votre domaine. Le développement piloté par les tests (TDD) et le développement piloté par le comportement (BDD) aident les équipes à concentrer leurs services sur la résolution des problèmes commerciaux.
+ Sélectionnez les [services AWS](https://aws.amazon.com/microservices/) qui répondent le mieux aux exigences de votre domaine d’activité et à votre [architecture de microservices](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html) :
+ [AWS sans serveur](https://aws.amazon.com/serverless/) permet à votre équipe de se concentrer sur une logique de domaine spécifique au lieu de gérer les serveurs et l’infrastructure.
+ [Les conteneurs à AWS](https://aws.amazon.com/containers/) simplifient la gestion de votre infrastructure afin que vous puissiez vous concentrer sur les exigences de votre domaine.
+ [Les bases de données sur mesure](https://aws.amazon.com/products/databases/) vous permettent d’adapter les exigences de votre domaine au type de base de données le mieux adapté.
+ [Création d’architectures hexagonales sur AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) décrit un cadre permettant d’intégrer une logique métier à des services en procédant de manière rétroactive à partir d’un domaine métier afin de répondre à des exigences fonctionnelles, puis d’associer des adaptateurs d’intégration. Les modèles qui séparent les détails de l’interface de la logique métier avec les services AWS aident les équipes à se concentrer sur les fonctionnalités du domaine et à améliorer la qualité des logiciels.
## Ressources
**Bonnes pratiques associées:**
+ [REL03-BP01 Choisissez comment segmenter votre charge de travail](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP03 Fournir des contrats de service par API](rel_service_architecture_api_contracts.md)
**Documents connexes :**
+ [Microservices AWS](https://aws.amazon.com/microservices/)
+ [Implémentation des microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Comment convertir un monolithe en microservices](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Premiers pas avec DDD en présence de systèmes hérités](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [ Conception axée sur le domaine : aborder la complexité au cœur du logiciel ](https://www.amazon.com/gp/product/0321125215)
+ [ Création d’architectures hexagonales sur AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)
+ [ Décomposition des monolithes en 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)
+ [ Messages entre contextes limités ](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)
+ [ Microservices ](https://www.martinfowler.com/articles/microservices.html)
+ [ Développement piloté par les tests ](https://en.wikipedia.org/wiki/Test-driven_development)
+ [ Développement axé sur le comportement ](https://en.wikipedia.org/wiki/Behavior-driven_development)
**Exemples connexes :**
+ [ Conception de microservices natifs cloud sur AWS (extrait de DDD/EventStormingWorkshop) ](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main)
**Outils associés :**
+ [AWS CloudBases de données](https://aws.amazon.com/products/databases/)
+ [Sans serveur activé sur AWS](https://aws.amazon.com/serverless/)
+ [ Conteneurs à AWS](https://aws.amazon.com/containers/)
# REL03-BP03 Fournir des contrats de service par API
Les contrats de service sont des accords documentés entre API producteurs et consommateurs définis dans une définition lisible par API machine. Une stratégie de gestion des versions des contrats permet aux consommateurs de continuer à utiliser l'existant API et de migrer leurs applications vers une version plus récente API lorsqu'elles sont prêtes. Le déploiement du producteur peut avoir lieu à tout moment tant que le contrat est respecté. Les équipes de service peuvent utiliser la pile technologique de leur choix pour exécuter le API contrat.
**Résultat escompté :** les applications conçues avec des architectures orientées services ou microservices sont capables de fonctionner de manière indépendante tout en intégrant une dépendance à l'environnement d'exécution. Les modifications apportées à un API consommateur ou à un producteur n'interrompent pas la stabilité de l'ensemble du système lorsque les deux parties suivent un API contrat commun. Les composants qui communiquent via le service APIs peuvent exécuter des versions fonctionnelles indépendantes, mettre à niveau les dépendances d'exécution ou basculer vers un site de reprise après sinistre (DR) avec peu ou pas d'impact les uns sur les autres. En outre, les services discrets sont capables d’évoluer de manière indépendante en absorbant la demande de ressources sans que les autres services soient réduits horizontalement à l’unisson.
**Anti-modèles courants :**
+ Création d'un service APIs sans schémas fortement typés. Il en résulte APIs que cela ne peut pas être utilisé pour générer des API liaisons et des charges utiles qui ne peuvent pas être validées par programmation.
+ Ne pas adopter de stratégie de gestion des versions, qui oblige API les consommateurs à effectuer des mises à jour et à publier ou à échouer lorsque les contrats de service évoluent.
+ Messages d’erreur qui divulguent les détails de l’implémentation du service sous-jacent au lieu de décrire les échecs d’intégration dans le contexte et le langage du domaine.
+ Ne pas utiliser de API contrats pour développer des scénarios de test et API des mises en œuvre fictives afin de permettre des tests indépendants des composants du service.
**Avantages de l'établissement de cette meilleure pratique :** les systèmes distribués composés de composants communiquant par le biais de contrats de API service peuvent améliorer la fiabilité. Les développeurs peuvent détecter les problèmes potentiels dès le début du processus de développement en vérifiant le type lors de la compilation afin de vérifier que les demandes et les réponses respectent le API contrat et que les champs obligatoires sont présents. APIles contrats fournissent une interface autodocumentée claire APIs et fournissent une meilleure interopérabilité entre les différents systèmes et langages de programmation.
**Niveau d’exposition au risque si cette bonne pratique n’est pas respectée :** moyen
## Directives d’implémentation
Une fois que vous avez identifié les domaines commerciaux et déterminé la segmentation de votre charge de travail, vous pouvez développer votre serviceAPIs. Définissez d'abord des contrats de service lisibles par machine pourAPIs, puis implémentez une stratégie de gestion des API versions. Lorsque vous êtes prêt à intégrer des services via des protocoles courants tels que REST GraphQL ou des événements asynchrones, vous pouvez intégrer des AWS services dans votre architecture afin d'intégrer vos composants à l'aide de contrats bien typés. API
**AWS services pour les API contrats de service**
Intégrez AWS des services tels qu'[Amazon API Gateway](https://aws.amazon.com/api-gateway/) et [Amazon EventBridge](https://aws.amazon.com/eventbridge/) dans votre architecture pour utiliser des contrats de API service dans votre application. [AWS AppSync](https://aws.amazon.com/appsync/) Amazon API Gateway vous permet d'intégrer directement des AWS services natifs et d'autres services Web. APIGateway prend en charge la [APIspécification Open](https://github.com/OAI/OpenAPI-Specification) et le versionnement. AWS AppSync est un point de terminaison [GraphQL](https://graphql.org/) géré que vous configurez en définissant un schéma GraphQL pour définir une interface de service pour les requêtes, les mutations et les abonnements. Amazon EventBridge utilise des schémas d'événements pour définir des événements et générer des liaisons de code pour vos événements.
## Étapes d’implémentation
+ Tout d'abord, définissez un contrat pour votreAPI. Un contrat exprimera les capacités d'un API et définira des objets de données et des champs fortement typés pour l'APIentrée et la sortie.
+ Lorsque vous configurez APIs dans API Gateway, vous pouvez importer et exporter des API spécifications ouvertes pour vos points de terminaison.
+ [L'importation d'une API définition ouverte](https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html) simplifie la création de votre API et peut être intégrée à AWS l'infrastructure sous forme d'outils de code tels que le [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/)et [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/).
+ [L'exportation d'une API définition](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) simplifie l'intégration avec API les outils de test et fournit aux consommateurs de services une spécification d'intégration.
+ Vous pouvez définir et gérer GraphQL AWS AppSync en [définissant APIs un fichier de schéma GraphQL](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) pour générer votre interface de contrat et simplifier l'interaction avec des REST modèles complexes, plusieurs tables de base de données ou des services existants.
+ [AWS Amplify](https://aws.amazon.com/amplify/)les projets intégrés AWS AppSync génèrent des fichiers de JavaScript requêtes fortement typés à utiliser dans votre application, ainsi qu'une bibliothèque cliente AWS AppSync GraphQL pour les tables Amazon [DynamoDB](https://aws.amazon.com/dynamodb/).
+ Lorsque vous consommez des événements de service d'Amazon EventBridge, les événements adhèrent aux schémas qui existent déjà dans le registre des schémas ou que vous définissez avec l'Open API Spec. Avec un schéma défini dans le registre, vous pouvez également générer des liaisons client à partir du contrat de schéma afin d’intégrer votre code aux événements.
+ Extension ou version de votreAPI. L'extension d'une API est une option plus simple lorsque vous ajoutez des champs qui peuvent être configurés avec des champs facultatifs ou des valeurs par défaut pour les champs obligatoires.
+ JSONles contrats basés sur des protocoles tels que REST GraphQL peuvent être une bonne solution pour l'extension de contrat.
+ XMLdes contrats basés sur des protocoles tels que SOAP ceux qui devraient être testés auprès des consommateurs de services afin de déterminer la faisabilité d'une prolongation du contrat.
+ Lors du versionnement d'unAPI, envisagez d'implémenter le versionnage par proxy dans le cadre duquel une façade est utilisée pour prendre en charge les versions afin que la logique puisse être maintenue dans une base de code unique.
+ Avec API Gateway, vous pouvez utiliser [les mappages de demandes et de réponses](https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#transforming-request-response-body) pour simplifier l'absorption des modifications de contrat en établissant une façade pour fournir des valeurs par défaut pour les nouveaux champs ou pour supprimer les champs supprimés d'une demande ou d'une réponse. Avec cette approche, le service sous-jacent peut gérer une base de code unique.
## Ressources
**Bonnes pratiques associées :**
+ [REL03-BP01 Choisissez comment segmenter votre charge de travail](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Créer des services axés sur des domaines d’activité et la fonctionnalité](rel_service_architecture_business_domains.md)
+ [REL04-BP02 Implémenter des dépendances faiblement couplées](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP03 Contrôler et limiter les appels de nouvelle tentative](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP05 Définir les délais d'expiration des clients](rel_mitigate_interaction_failure_client_timeouts.md)
**Documents connexes :**
+ [Qu'est-ce qu'une API (interface de programmation d'applications) ?](https://aws.amazon.com/what-is/api/)
+ [Implémentation de microservices sur AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ Compromis des microservices ](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [ Microservices : une définition de ce nouveau terme architectural ](https://www.martinfowler.com/articles/microservices.html)
+ [Microservices sur AWS](https://aws.amazon.com/microservices/)
+ [Utilisation des extensions de API passerelle pour ouvrir API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions.html)
+ [Spécification ouverte API](https://github.com/OAI/OpenAPI-Specification)
+ [ GraphQL : schémas et types ](https://graphql.org/learn/schema/)
+ [liaisons EventBridge de code Amazon](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-code-bindings.html)
**Exemples connexes :**
+ [Amazon API Gateway : Configuration d'une application à REST API l'aide d'Open API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Amazon API Gateway vers l'application Amazon CRUD DynamoDB à l'aide d'Open API](https://serverlessland.com/patterns/apigw-ddb-openapi-crud?ref=search)
+ [Modèles modernes d'intégration des applications à l'ère du sans serveur : intégration des services de API passerelle](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)
+ [Implémentation du versionnement des API passerelles basé sur les en-têtes avec Amazon CloudFront](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/)
+ [AWS AppSync : création d’une application client ](https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app.html#aws-appsync-building-a-client-app)
**Vidéos connexes :**
+ [Utilisation d'Open API in AWS SAM pour gérer API Gateway](https://www.youtube.com/watch?v=fet3bh0QA80)
**Outils associés :**
+ [APIPasserelle Amazon](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [Amazon EventBridge](https://aws.amazon.com/eventbridge/)