# REL 3. Come si progetta l'architettura del servizio di carico di lavoro?
Creazione di carichi di lavoro altamente scalabili e affidabili utilizzando un'architettura orientata ai servizi (SOA) o un'architettura di microservizi. L'architettura orientata ai servizi (SOA) è la pratica di rendere i componenti software riutilizzabili tramite interfacce di servizio. L'architettura dei microservizi va oltre, per rendere i componenti più piccoli e semplici.
**Topics**
+ [REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Fornitura di contratti di servizio per API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro
La segmentazione del carico di lavoro è importante quando vengono determinati i requisiti di resilienza dell'applicazione. L'architettura monolitica deve essere evitata se possibile. Valuta invece con particolare attenzione quali componenti dell'applicazione possono essere suddivisi in microservizi. A seconda dei requisiti dell'applicazione, ciò potrebbe risultare in una combinazione di architettura orientata ai servizi (SOA) e microservizi, laddove possibile. I carichi di lavoro stateless sono maggiormente idonei a essere implementati come microservizi.
**Risultato desiderato:** i carichi di lavoro devono essere supportabili, scalabili e devono essere caratterizzati dalla minore interdipendenza possibile.
Quando scegli come segmentare il carico di lavoro, trova il giusto compromesso tra i vantaggi e le complessità. Ciò che è giusto per un nuovo prodotto al primo lancio è diverso dai requisiti di un carico di lavoro creato per ridimensionare le risorse. Durante la rifattorizzazione (riprogettazione) di un monolito, dovrai considerare la capacità dell'applicazione di supportare la suddivisione in servizi stateless. La suddivisione dei servizi in elementi più piccoli consente a team ristretti e ben definiti di svilupparli e gestirli. Tuttavia, servizi di piccole dimensioni possono introdurre complessità, che includono un eventuale aumento della latenza, un debug più complesso e un maggiore carico operativo.
**Anti-pattern comuni:**
+ Il [microservizio *Death Star*](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) rappresenta una situazione in cui i componenti atomici diventano così interdipendenti che un errore verificatosi in un componente genera un errore molto più grande, rendendo i componenti rigidi e fragili se considerati come monolito.
**Vantaggi dell'adozione di questa best practice:**
+ Segmenti più specifici comportano maggiore agilità, flessibilità organizzativa e scalabilità.
+ Riduzione dell'impatto derivante dall'interruzione dei servizi.
+ I componenti dell'applicazione possono avere requisiti di disponibilità diversi, che a loro volta possono essere supportati da una segmentazione più atomica.
+ Responsabilità ben definite per i team che supportano il carico di lavoro.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
Scegli il tipo di architettura in base al tipo di segmentazione del carico di lavoro. Scegli una SOA o un'architettura di microservizi (o, in alcuni rari casi, un'architettura monolitica). Anche se scegli di iniziare con un'architettura monolitica, devi assicurarti che sia modulare e possa evolvere in SOA o microservizi man mano che il prodotto si dimensiona con l'adozione da parte degli utenti. La SOA e i microservizi offrono rispettivamente una segmentazione più piccola, preferita come architettura moderna scalabile e affidabile, ma ci sono compromessi da considerare soprattutto quando si distribuisce un'architettura di microservizi.
Uno dei principali compromessi è che ora disponi di un'architettura di calcolo distribuita che può rendere più difficile il raggiungimento dei requisiti di latenza degli utenti ed è presente un'ulteriore complessità nel debug e nel tracciamento delle interazioni degli utenti. Puoi utilizzare AWS X-Ray per risolvere questo problema. Un altro effetto da considerare è l'aumento della complessità operativa man mano che aumenta il numero di applicazioni che gestisci, che richiede la distribuzione di più componenti di indipendenza.
![\[Diagramma che illustra il confronto tra architettura monolitica, orientata ai servizi e di microservizi\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/monolith-soa-microservices-comparison.png)
## Passaggi dell'implementazione
+ Determina l'architettura più appropriata per rifattorizzare (riprogettare) o creare l'applicazione. SOA e microservizi offrono segmentazione rispettivamente di dimensioni minori, preferita in quanto architettura moderna, scalabile e affidabile. SOA può essere un buon compromesso per ottenere una segmentazione di dimensioni minori, evitando al contempo alcune delle complessità dei microservizi. Per ulteriori dettagli, consulta [I compromessi dei microservizi](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Se il carico di lavoro è adatto e la tua organizzazione può supportarla, è consigliabile utilizzare un'architettura di microservizi per ottenere la massima agilità e affidabilità. Per ulteriori dettagli, consulta [Implementing Microservices on AWS (Implementazione di microservizi in AWS).](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ Considera l'ipotesi di attenerti al modello [*Strangler* Fig](https://martinfowler.com/bliki/StranglerFigApplication.html) per eseguire la rifattorizzazione (riprogettazione) di un monolito in componenti più piccoli. Ciò comporta la graduale sostituzione di componenti specifici dell'applicazione con nuove applicazioni e nuovi servizi. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) funge da punto di partenza per la rifattorizzazione incrementale. Per ulteriori dettagli, consulta [Seamlessly migrate on-premises legacy workloads using a strangler pattern (Migrazione senza problemi di carichi di lavoro legacy on-premise mediante un modello Strangler)](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ L'implementazione di microservizi può richiedere un meccanismo di individuazione dei servizi per consentire ai servizi distribuiti di comunicare tra loro. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) può essere utilizzato con architetture orientate ai servizi per offrire rilevamento e accesso affidabili ai servizi. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) può inoltre essere utilizzato per il rilevamento dinamico dei servizi basato su DNS.
+ In caso di migrazione da un monolito a una SOA, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) può aiutare a colmare il divario come bus del servizio durante la riprogettazione delle applicazioni legacy nel cloud.
+ Per i monoliti esistenti con un unico database condiviso, scegli come riorganizzare i dati in segmenti più piccoli. Questa riorganizzazione può avvenire per unità aziendale, schema di accesso o struttura dei dati. A questo punto del processo di rifattorizzazione (riprogettazione), deve orientare la scelta verso un database di tipo relazionale o non relazionale (NoSQL). Per ulteriori dettagli, consulta [From SQL to NoSQL (Da SQL a NoSQL)](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Livello di impegno per il piano di implementazione:** alto
## Risorse
**Best practice correlate:**
+ [REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici](rel_service_architecture_business_domains.md)
**Documenti correlati:**
+ [Amazon API Gateway: configurazione di una REST API mediante OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [Cosa si intende per architettura orientata ai servizi?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Bounded Context (un modello centrale in Domain-Driven Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [I compromessi dei microservizi](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservizi: una definizione di questo nuovo termine di architettura](https://www.martinfowler.com/articles/microservices.html)
+ [Implementazione di microservizi in AWS](https://aws.amazon.com/microservices/)
+ [What is AWS App Mesh? (Che cos'è AWS App Mesh?)](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Esempi correlati:**
+ [Iterative App Modernization Workshop (Workshop sulla modernizzazione delle applicazioni interattive)](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Video correlati:**
+ [Delivering Excellence with Microservices on AWS (Implementazione dell'eccellenza con i microservizi in AWS)](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici
L'architettura orientata ai servizi (SOA) definisce servizi con funzioni ben delineate determinate dalle esigenze aziendali. I microservizi utilizzano modelli di dominio e contesto delimitato per tracciare i limiti dei servizi lungo i confini del contesto aziendale. Concentrarsi sui domini e sulle funzionalità aziendali aiuta i team a definire requisiti di affidabilità indipendenti per i propri servizi. I contesti delimitati isolano e incapsulano la logica aziendale, consentendo ai team di ragionare meglio su come gestire gli errori.
**Risultato desiderato:** ingegneri e parti interessate aziendali definiscono congiuntamente contesti delimitati e li utilizzano per progettare sistemi come servizi che soddisfano funzioni aziendali specifiche. Questi team utilizzano pratiche consolidate come l'event storming per definire i requisiti. Le nuove applicazioni sono concepite come servizi con confini ben definiti e con accoppiamento debole. I monoliti esistenti vengono scomposti in [contesti delimitati](https://martinfowler.com/bliki/BoundedContext.html) e la progettazione dei sistemi si sposta verso architetture SOA o microservizi. Quando i monoliti vengono rifattorizzati, vengono applicati approcci consolidati come contesti a bolle e schemi di decomposizione dei monoliti.
I servizi orientati al dominio vengono eseguiti come uno o più processi che non condividono lo stato. Rispondono in modo indipendente alle fluttuazioni della domanda e gestiscono gli scenari di errore alla luce dei requisiti specifici del dominio.
**Anti-pattern comuni:**
+ I team sono formati su domini tecnici specifici come UI e UX, middleware o database anziché su domini aziendali specifici.
+ Le applicazioni coprono le responsabilità di dominio. I servizi che coprono contesti delimitati possono essere più difficili da gestire, richiedere maggiori sforzi di test ed esigere la partecipazione di più team di dominio agli aggiornamenti software.
+ Le dipendenze a livello di dominio, come le librerie di entità di dominio, sono condivise tra i servizi, in modo che le modifiche per il dominio di un servizio richiedano modifiche ad altri domini dei servizi.
+ I contratti di servizio e la logica aziendale non esprimono le entità in un linguaggio di dominio comune e coerente, con il risultato di livelli di traduzione che complicano i sistemi e aumentano le attività di debug.
**Vantaggi dell'adozione di questa best practice:** le applicazioni sono progettate come servizi indipendenti limitati da domini aziendali e utilizzano un linguaggio aziendale comune. I servizi sono testabili e implementabili in modo indipendente. I servizi soddisfano i requisiti di resilienza specifici del dominio implementato.
**Livello di rischio associato se questa best practice non fosse adottata:** alto
## Guida all'implementazione
La decisione basata sul dominio (DDD) costituisce l'approccio fondamentale alla progettazione e alla creazione di software attorno ai domini aziendali. È utile utilizzare un framework esistente quando si creano servizi incentrati sui domini aziendali. Quando si utilizzano applicazioni monolitiche esistenti, è possibile sfruttare i modelli di decomposizione che forniscono tecniche consolidate per modernizzare le applicazioni in servizi.
![\[Diagramma di flusso che illustra l'approccio incentrato sulla decisione basata sul dominio.\]](http://docs.aws.amazon.com/it_it/wellarchitected/2023-10-03/framework/images/domain-driven-decision.png)
## Passaggi dell'implementazione
+ I team possono organizzare eventi di [event storming](https://serverlessland.com/event-driven-architecture/visuals/event-storming) per identificare rapidamente eventi, comandi, aggregati e domini.
+ Una volta che le entità e le funzioni di dominio sono state definite in un contesto di dominio, puoi dividere il tuo dominio in servizi utilizzando il [contesto delimitato](https://martinfowler.com/bliki/BoundedContext.html), dove le entità che condividono caratteristiche e attributi simili vengono raggruppate insieme. Con il modello diviso in contesti, emerge un modello su come delimitare i microservizi.
+ Ad esempio, le entità del sito Web Amazon.com possono includere elementi quali pacchetti, distribuzione, pianificazione, prezzo, sconto e valuta.
+ Il pacchetto, la distribuzione e la pianificazione sono raggruppati nel contesto di spedizione, mentre il prezzo, lo sconto e la valuta sono raggruppati nel contesto dei prezzi.
+ [Scomporre i monoliti in microservizi](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) delinea i modelli per la rifattorizzazione dei microservizi. L'utilizzo di modelli per la decomposizione in base a capacità aziendale, sottodominio o transazione si allinea bene agli approcci basati sul dominio.
+ Tecniche di strategia come il [contesto a bolle](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) consentono di introdurre la decisione basata sul dominio (DDD) in applicazioni esistenti o precedenti senza riscritture anticipate e impegni completi nei confronti di DDD. In un approccio basato sul contesto a bolle, viene stabilito un contesto delimitato utilizzando una mappatura e un coordinamento dei servizi, oppure il [livello anti-danneggiamento (ACL)](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context), che protegge il modello di dominio appena definito dalle influenze esterne.
Dopo aver eseguito l'analisi del dominio e definito le entità e i contratti di servizio, i team possono utilizzare i servizi AWS per implementare la progettazione basata sul dominio come servizi basati sul cloud.
+ Inizia a sviluppare definendo test che applichino le regole aziendali del tuo dominio. Lo sviluppo basato sui test (TDD) e lo sviluppo basato sul comportamento (BDD) aiutano i team a focalizzare i servizi sulla risoluzione dei problemi aziendali.
+ Seleziona i [servizi AWS](https://aws.amazon.com/microservices/) che soddisfano al meglio i requisiti del tuo dominio aziendale e l' [architettura di microservizi](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html):
+ [AWS Serverless](https://aws.amazon.com/serverless/) consente al team di concentrarsi su una logica di dominio specifica anziché sulla gestione di server e infrastrutture.
+ [I container in AWS](https://aws.amazon.com/containers/) semplificano la gestione della tua infrastruttura, in modo da poterti concentrare sui requisiti del tuo dominio.
+ [I database dedicati](https://aws.amazon.com/products/databases/) ti aiutano ad adattare i requisiti del tuo dominio al tipo di database più idoneo.
+ [La creazione di architetture esagonali su AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) delinea un framework per integrare la logica aziendale nei servizi che funzionano a ritroso da un dominio aziendale per soddisfare i requisiti funzionali e, quindi, per collegare adattatori di integrazione. I modelli che separano i dettagli dell'interfaccia dalla logica aziendale con i servizi AWS aiutano i team a concentrarsi sulla funzionalità del dominio e a migliorare la qualità del software.
## Risorse
**Best practice correlate:**
+ [REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP03 Fornitura di contratti di servizio per API](rel_service_architecture_api_contracts.md)
**Documenti correlati:**
+ [Microservizi AWS](https://aws.amazon.com/microservices/)
+ [Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [How to break a Monolith into Microservices (Come trasformare un monolite in microservizi)](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Getting Started with DDD when Surrounded by Legacy Systems (Iniziare con il DDD quando si è circondati da sistemi legacy)](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [ Domain-Driven Design: Tackling Complexity in the Heart of Software (Progettazione basata sul dominio: affrontare la complessità al cuore del software) ](https://www.amazon.com/gp/product/0321125215)
+ [ La creazione di architetture esagonali su AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)
+ [ Scomporre i monoliti in microservizi ](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html)
+ [ Event Storming ](https://serverlessland.com/event-driven-architecture/visuals/event-storming)
+ [ Messaggi tra contesti limitati ](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)
+ [ Microservizi ](https://www.martinfowler.com/articles/microservices.html)
+ [ Sviluppo basato su test ](https://en.wikipedia.org/wiki/Test-driven_development)
+ [ Sviluppo basato sul comportamento ](https://en.wikipedia.org/wiki/Behavior-driven_development)
**Esempi correlati:**
+ [ Workshop sul cloud aziendale nativo ](https://catalog.us-east-1.prod.workshops.aws/workshops/0466c70e-4216-4352-98d9-5a8af59c86b2/en-US)
+ [ Progettazione di microservizi cloud nativi su AWS (da DDD/EventStormingWorkshop) ](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main)
**Strumenti correlati:**
+ [ Database su Cloud AWS](https://aws.amazon.com/products/databases/)
+ [ Serverless su AWS](https://aws.amazon.com/serverless/)
+ [ Container in AWS](https://aws.amazon.com/containers/)
# REL03-BP03 Fornitura di contratti di servizio per API
I contratti di assistenza sono accordi documentati tra produttori di API e utenti definiti in una definizione di API leggibile dal computer. Una strategia di controllo delle versioni dei contratti consente agli utenti di continuare a utilizzare l'API esistente e migrare le applicazioni a un'API più recente quando sono pronte. L'implementazione da parte del produttore può avvenire in qualsiasi momento, purché il processo sia conforme al contratto. Il team dei servizi può utilizzare lo stack tecnologico scelto per soddisfare il contratto API.
**Risultato desiderato:**
**Anti-pattern comuni:** Le applicazioni realizzate con architetture orientate ai servizi o con architetture di microservizi sono in grado di funzionare in modo indipendente pur essendo caratterizzate da una dipendenza dal runtime integrata. Le modifiche apportate a un utente o produttore di API non pregiudicano la stabilità dell'intero sistema quando entrambe le parti sono conformi a un contratto API comune. I componenti che comunicano tramite le API di servizio possono eseguire release funzionali indipendenti, aggiornamenti delle dipendenze di runtime o eseguire il failover su un sito di ripristino di emergenza con un impatto reciproco minimo o nullo. Inoltre, i servizi discreti sono in grado di eseguire il dimensionamento in modo indipendente assorbendo la richiesta di risorse senza che gli altri servizi debbano ridimensionarsi di conseguenza.
+ Creazione di API di servizio senza schemi fortemente tipizzati. Ciò si traduce in API che non possono essere utilizzate per generare collegamenti API e payload che non possono essere convalidati a livello di codice.
+ Non adottare una strategia di controllo delle versioni, che costringa gli utenti delle API all'aggiornamento e rilascio o all'esito negativo dell'operazione al variare dei contratti di servizio.
+ Messaggi di errore che divulgano dettagli sull'implementazione del servizio sottostante anziché descrivere errori di integrazione nel contesto e nel linguaggio del dominio.
+ Non utilizzare contratti API per sviluppare casi di test e simulare implementazioni API per consentire test indipendenti dei componenti del servizio.
**Vantaggi dell'adozione di questa best practice:** i sistemi distribuiti composti da componenti che comunicano tramite contratti di servizio API possono migliorare l'affidabilità. Gli sviluppatori possono rilevare potenziali problemi nelle prime fasi del processo di sviluppo con il controllo del tipo durante la compilazione per verificare che le richieste e le risposte siano conformi al contratto API e che i campi obbligatori siano presenti. I contratti API forniscono una chiara interfaccia di documentazione automatica per le API e garantiscono una migliore interoperabilità tra sistemi e linguaggi di programmazione diversi.
**Livello di rischio associato se questa best practice non fosse adottata:** medio
## Guida all'implementazione
Dopo aver individuato i domini aziendali e determinato la segmentazione del carico di lavoro, puoi sviluppare le API dei tuoi servizi. Innanzitutto, definisci contratti di servizio leggibili dal computer per le API, quindi implementa una strategia di controllo delle versioni delle API. Quando sei pronto per integrare servizi su protocolli comuni come REST, GraphQL o eventi asincroni, puoi incorporare servizi AWS nell'architettura per integrare i componenti con contratti API fortemente tipizzati.
**I servizi AWS per i contratti API di servizio**
includono servizi AWS come [Amazon API Gateway](https://aws.amazon.com/api-gateway/), [AWS AppSync](https://aws.amazon.com/appsync/)e [Amazon EventBridge](https://aws.amazon.com/eventbridge/) nell'architettura per utilizzare i contratti di servizio API nell'applicazione. Amazon API Gateway è un valido supporto per l'integrazione con i servizi AWS direttamente nativi e altri servizi Web. API Gateway supporta la [specifica OpenAPI](https://github.com/OAI/OpenAPI-Specification) e il controllo delle versioni. AWS AppSync è un endpoint [gestito da GraphQL](https://graphql.org/) configurato definendo uno schema GraphQL per definire un'interfaccia di servizio per query, mutazioni e sottoscrizioni. Amazon EventBridge utilizza schemi di eventi per definire eventi e generare associazioni di codice per gli eventi.
## Passaggi dell'implementazione
+ Definisci innanzitutto un contratto per la tua API. Un contratto esprimerà le capacità di un'API e definirà oggetti e campi di dati fortemente tipizzati per l'input e l'output dell'API.
+ Quando configuri le API in API Gateway, puoi importare ed esportare le specifiche OpenAPI per gli endpoint.
+ [L'importazione di una definizione OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html) semplifica la creazione dell'API e può essere integrata con l'infrastruttura AWS come strumenti di codice come [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/) e [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/).
+ [L'esportazione di una definizione API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) semplifica l'integrazione con gli strumenti di test delle API e fornisce agli utenti di servizi una specifica di integrazione.
+ Puoi definire e gestire le API GraphQL con AWS AppSync [mediante la definizione di un file di schema GraphQL](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) per generare l'interfaccia del contratto e semplificare l'interazione con modelli REST complessi, più tabelle di database o servizi legacy.
+ [I progetti AWS Amplify](https://aws.amazon.com/amplify/) integrati con AWS AppSync generano file di query JavaScript fortemente tipizzati da utilizzare nell'applicazione, nonché una libreria client GraphQL AWS AppSync per le tabelle [Amazon DynamoDB](https://aws.amazon.com/dynamodb/) .
+ Quando si utilizzano eventi di servizio da Amazon EventBridge, gli eventi sono conformi agli schemi già esistenti nel registro degli schemi o definiti con la specifica OpenAPI. Con uno schema definito nel registro, puoi anche generare associazioni client dal contratto dello schema per integrare il codice con gli eventi.
+ Estensione o definizione della versione dell'API. L'estensione di un'API è un'opzione più semplice quando si aggiungono campi che possono essere configurati con campi facoltativi o valori predefiniti per i campi obbligatori.
+ I contratti basati su JSON per protocolli come REST e GraphQL possono essere adatti per l'estensione del contratto.
+ I contratti basati su XML per protocolli come SOAP devono essere testati con gli utenti dei servizi per determinare se l'estensione del contratto è possibile.
+ Quando esegui il controllo delle versioni di un'API, valuta la possibilità di implementare il controllo delle versioni proxy laddove un lato viene usato per supportare le versioni in modo che la logica possa essere gestita in un'unica base di codice.
+ Con API Gateway puoi usare [mappature di richieste e risposte](https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#transforming-request-response-body) per semplificare l'inclusione delle modifiche del contratto stabilendo un lato per fornire valori predefiniti per i nuovi campi o per eliminare i campi rimossi da una richiesta o una risposta. Con questo approccio, il servizio sottostante può avere un'unica base di codice.
## Risorse
**Best practice correlate:**
+ [REL03-BP01 Scelta del tipo di segmentazione del carico di lavoro](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Creazione di servizi focalizzati su domini e funzionalità aziendali specifici](rel_service_architecture_business_domains.md)
+ [REL04-BP02 Implementazione di dipendenze "loosely coupled"](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP03 Controllo e limitazione delle chiamate di ripetizione](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP05 Impostazione dei timeout dei client](rel_mitigate_interaction_failure_client_timeouts.md)
**Documenti correlati:**
+ [ Cos'è un'interfaccia di programmazione dell'applicazione (API)? ](https://aws.amazon.com/what-is/api/)
+ [ Implementazione di microservizi in AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ I compromessi dei microservizi ](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [ Microservizi: una definizione di questo nuovo termine di architettura ](https://www.martinfowler.com/articles/microservices.html)
+ [ Microservizi in AWS](https://aws.amazon.com/microservices/)
+ [ Utilizzo delle estensioni API Gateway di OpenAPI ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions.html)
+ [ Specifica OpenAPI ](https://github.com/OAI/OpenAPI-Specification)
+ [ GraphQL: schemi e tipi ](https:/graphql.org/learn/schema)
+ [ Associazioni di codice Amazon EventBridge ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-code-bindings.html)
**Esempi correlati:**
+ [ Amazon API Gateway: configurazione di una REST API mediante OpenAPI ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [ Applicazione CRUD da Amazon API Gatewaya Amazon DynamoDB utilizzando OpenAPI ](https://serverlessland.com/patterns/apigw-ddb-openapi-crud?ref=search)
+ [ Modelli di integrazione di applicazioni moderne in un'era serverless: integrazione dei servizi API Gateway ](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)
+ [ Implementazione del controllo delle versioni API Gateway basato sull'intestazione con Amazon CloudFront ](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/)
+ [AWS AppSync: creazione di un'applicazione client ](https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app.html#aws-appsync-building-a-client-app)
**Video correlati:**
+ [ Utilizzo di OpenAPI AWS SAM per la gestione di API Gateway ](https://www.youtube.com/watch?v=fet3bh0QA80)
**Strumenti correlati:**
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)