# Diseño de la arquitectura de servicio de su carga de trabajo
Desarrolle cargas de trabajo escalables y fiables mediante una arquitectura orientada a servicios (SOA) o una arquitectura de microservicios. La arquitectura orientada a servicios (SOA) es hacer que los componentes de software se puedan reutilizar mediante interfaces de servicio. La arquitectura de microservicios va más allá, para hacer que los componentes sean más pequeños y sencillos.
Las interfaces de arquitectura orientada a servicios (SOA) utilizan estándares de comunicación comunes para que puedan incorporarse rápidamente a las nuevas cargas de trabajo. La SOA sustituyó a la práctica de crear arquitecturas monolíticas, que consistían en unidades indivisibles e interdependientes.
En AWS, siempre hemos utilizado SOA, pero ahora hemos optado por crear nuestros sistemas mediante microservicios. Si bien los microservicios tienen varias cualidades atractivas, el beneficio más importante para la disponibilidad es que estos son más pequeños y sencillos. Permiten diferenciar la disponibilidad requerida de diferentes servicios y, por lo tanto, centrar las inversiones más específicamente en los microservicios que tienen mayores necesidades de disponibilidad. Por ejemplo, para entregar páginas de información de productos en Amazon.com (“páginas de detalles”), se invocan cientos de microservicios para crear porciones discretas de la página. Si bien hay algunos servicios que deben estar disponibles para proporcionar el precio y los detalles del producto, la gran mayoría del contenido de la página puede simplemente excluirse si el servicio no está disponible. Incluso las fotos y las reseñas no son necesarias para proporcionar una experiencia en la que un cliente pueda comprar un producto.
**Topics**
+ [REL03-BP01 Elección de cómo segmentar su carga de trabajo](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Desarrollo de servicios centrados en funcionalidades y dominios empresariales específicos](rel_service_architecture_business_domains.md)
+ [REL03-BP03 Disposición de contratos de servicio por cada API](rel_service_architecture_api_contracts.md)
# REL03-BP01 Elección de cómo segmentar su carga de trabajo
La segmentación de la carga de trabajo es importante a la hora de determinar los requisitos de resiliencia de su aplicación. La arquitectura monolítica debe evitarse siempre que sea posible. En su lugar, considere detenidamente qué componentes de la aplicación pueden dividirse en microservicios. Según los requisitos de su aplicación, esto puede terminar siendo una combinación de una arquitectura orientada a servicios (SOA) con microservicios cuando sea posible. Las cargas de trabajo que son capaces de no tener estado son más capaces de implementarse como microservicios.
**Resultado deseado:** las cargas de trabajo se deben admitir, ser escalables y tener el acoplamiento más débil que sea posible.
A la hora de elegir cómo segmentar la carga de trabajo, hay que sopesar las ventajas frente a las complejidades. Lo que puede ser adecuado para un nuevo producto encaminado a su primer lanzamiento es diferente a lo que necesita una carga de trabajo creada para escalarse desde el principio. Al refactorizar un monolito existente, tendrá que considerar en qué medida soportará la aplicación una descomposición hacia la falta de estado. Dividir los servicios en partes más pequeñas permite que equipos pequeños y bien definidos los desarrollen y administren. No obstante, los servicios más pequeños pueden introducir complejidades que incluyen un aumento de la latencia, una depuración más compleja y un mayor lastre operativo.
**Patrones comunes de uso no recomendados:**
+ La [*Estrella de la muerte* de microservicios](https://mrtortoise.github.io/architecture/lean/design/patterns/ddd/2018/03/18/deathstar-architecture.html) es una situación en la que los componentes atómicos son tan interdependientes que el error de uno de ellos provoca un error mucho mayor, lo que hace que los componentes sean tan rígidos y frágiles como un monolito.
**Beneficios de establecer esta práctica:**
+ Los segmentos más específicos conducen a una mayor agilidad, flexibilidad organizativa y escalabilidad.
+ Reducción del impacto de las interrupciones del servicio.
+ Los componentes de la aplicación pueden tener diferentes requisitos de disponibilidad, que pueden soportarse mediante una segmentación más atómica.
+ Responsabilidades bien definidas para los equipos que apoyan la carga de trabajo.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
Seleccione el tipo de arquitectura en función de cómo va a segmentar su carga de trabajo. Seleccione una SOA o una arquitectura de microservicios (o, en algunos casos raros, una arquitectura monolítica). Incluso si decide empezar con una arquitectura monolítica, debe asegurarse de que sea modular y de que pueda evolucionar hacia SOA o microservicios de forma definitiva, a medida que su producto escala con la adopción por parte de los usuarios. La SOA y los microservicios ofrecen respectivamente una segmentación más pequeña, lo que resulta preferible como arquitectura moderna escalable y fiable, pero existen compensaciones a tener en cuenta, especialmente al implementar una arquitectura de microservicios.
Una compensación principal es que se dispone de una arquitectura de computación distribuida que puede dificultar el cumplimiento de los requisitos de latencia del usuario y existe una complejidad adicional en la depuración y el rastreo de las interacciones del usuario. Puede utilizar AWS X-Ray para ayudarle a resolver este problema. Otro efecto que hay que tener en cuenta es el aumento de la complejidad operativa a medida que aumenta el número de aplicaciones que se administran, lo que requiere la implementación de componentes con varias independencias.
![\[Diagrama que muestra una comparación entre las arquitecturas monolíticas, orientadas al servicio y de microservicios\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/monolith-soa-microservices-comparison.png)
## Pasos para la implementación
+ Determine la arquitectura adecuada para refactorizar o desarrollar su aplicación. La SOA y los microservicios ofrecen respectivamente una segmentación más pequeña, lo que resulta preferible como arquitectura moderna escalable y fiable. La SOA puede ofrecer un término intermedio ideal para conseguir una segmentación más pequeña y, a la vez, evitar algunas de las complejidades de los microservicios. Para obtener más información, consulte [Microservice Trade-Offs](https://martinfowler.com/articles/microservice-trade-offs.html).
+ Si su carga de trabajo lo admite y su organización puede permitírselo, debería usar una arquitectura de microservicios para conseguir la mejor agilidad y fiabilidad. Para obtener más información, consulte [Implementing Microservices on AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html).
+ Considere la posibilidad de seguir el [patrón del *higo estrangulador*](https://martinfowler.com/bliki/StranglerFigApplication.html) para refactorizar un monolito en componentes más pequeños. Esto implica reemplazar gradualmente componentes específicos de la aplicación por nuevas aplicaciones y servicios. [AWS Migration Hub Refactor Spaces](https://docs.aws.amazon.com/migrationhub-refactor-spaces/latest/userguide/what-is-mhub-refactor-spaces.html) actúa como punto de partida para la refactorización incremental. Para obtener más información, consulte [Seamlessly migrate on-premises legacy workloads using a strangler pattern](https://aws.amazon.com/blogs/architecture/seamlessly-migrate-on-premises-legacy-workloads-using-a-strangler-pattern/).
+ La implementación de microservicios puede necesitar de un mecanismo de detección de servicios que permita que estos servicios distribuidos se comuniquen entre sí. [AWS App Mesh](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html) se puede utilizar con arquitecturas orientadas a los servicios para proporcionar una detección y un acceso fiables a estos. [AWS Cloud Map](https://aws.amazon.com/cloud-map/) también se puede utilizar para la detección dinámica de servicios basada en DNS.
+ Si va a migrar de un entorno monolítico a SOA, [Amazon MQ](https://docs.aws.amazon.com/amazon-mq/latest/developer-guide/welcome.html) puede ayudarle a cerrar la brecha, en calidad de bus de servicio, a la hora de rediseñar aplicaciones heredadas en la nube.
+ Para los monolitos existentes con una única base de datos compartida, elija cómo reorganizar los datos en segmentos más pequeños. Puede ser por unidad de negocio, patrón de acceso o estructura de datos. En este punto del proceso de refactorización, debe elegir entre una base de datos de tipo relacional o no relacional (NoSQL). Para obtener más información, consulte [From SQL to NoSQL](https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/SQLtoNoSQL.html).
**Nivel de esfuerzo para el plan de implementación:** alto
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL03-BP02 Desarrollo de servicios centrados en funcionalidades y dominios empresariales específicos](rel_service_architecture_business_domains.md)
**Documentos relacionados:**
+ [Amazon API Gateway: Configuring a REST API Using OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [¿Qué es la arquitectura orientada a servicios (SOA)?](https://aws.amazon.com/what-is/service-oriented-architecture/)
+ [Bounded Context (a central pattern in Domain-Driven Design)](https://martinfowler.com/bliki/BoundedContext.html)
+ [Implementing Microservices on AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [Microservice Trade-Offs](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [Microservices - a definition of this new architectural term](https://www.martinfowler.com/articles/microservices.html)
+ [Microservicios en AWS](https://aws.amazon.com/microservices/)
+ [¿Qué es AWS App Mesh?](https://docs.aws.amazon.com/app-mesh/latest/userguide/what-is-app-mesh.html)
**Ejemplos relacionados:**
+ [Iterative App Modernization Workshop](https://catalog.us-east-1.prod.workshops.aws/workshops/f2c0706c-7192-495f-853c-fd3341db265a/en-US/intro)
**Videos relacionados:**
+ [Delivering Excellence with Microservices on AWS](https://www.youtube.com/watch?v=otADkIyugzY)
# REL03-BP02 Desarrollo de servicios centrados en funcionalidades y dominios empresariales específicos
La arquitectura orientada a servicios (SOA) define servicios con funciones bien delineadas y determinadas por necesidades empresariales. Los microservicios utilizan modelos de dominio y contextos delimitados para trazar los límites de los servicios en los límites del contexto empresarial. Centrarse en los dominios y las funcionalidades empresariales ayuda a los equipos a definir requisitos de fiabilidad independientes para sus servicios. Los contextos delimitados aíslan y encapsulan la lógica empresarial, lo que permite a los equipos mejorar la forma en que gestionan los errores.
**Resultado deseado:** los ingenieros y las partes interesadas de la empresa definen conjuntamente los contextos delimitados y los utilizan para diseñar sistemas como servicios que cumplan funciones empresariales específicas. Estos equipos utilizan prácticas establecidas, como las tormentas de eventos, para definir los requisitos. Las nuevas aplicaciones se diseñan como límites bien definidos de servicios y con acoplamiento débil. Los monolitos existentes se descomponen en [contextos delimitados](https://martinfowler.com/bliki/BoundedContext.html) y los diseños de sistemas avanzan hacia arquitecturas SOA o de microservicios. Cuando los monolitos se refactorizan, se aplican enfoques establecidos, como contextos burbuja y patrones de descomposición de monolitos.
Los servicios orientados al dominio se ejecutan como uno o más procesos que no comparten el estado. Responden de forma independiente a las fluctuaciones de la demanda y gestionan los escenarios de error en función de los requisitos específicos del dominio.
**Patrones comunes de uso no recomendados:**
+ Se forman equipos en torno a dominios técnicos específicos, como la interfaz de usuario y la experiencia de usuario, el middleware o la base de datos, en lugar de formarse en torno a dominios empresariales específicos.
+ Las aplicaciones abarcan las responsabilidades del dominio. Los servicios que abarcan contextos delimitados pueden ser más difíciles de mantener, exigen más pruebas y requieren la participación de equipos de varios dominios en las actualizaciones del software.
+ Las dependencias de dominio, como las bibliotecas de entidades de dominio, se comparten entre los servicios, de modo que los cambios en un dominio de servicio requieren cambios en otros dominios de servicio
+ Los contratos de servicio y la lógica empresarial no expresan las entidades en un lenguaje de dominio común y coherente, lo que genera capas de traducción que complican los sistemas e incrementan los esfuerzos de depuración.
**Beneficios de establecer esta práctica recomendada:** las aplicaciones se diseñan como servicios independientes delimitados por dominios empresariales y utilizan un lenguaje empresarial común. Los servicios se pueden probar e implementar de forma independiente. Los servicios cumplen los requisitos de resiliencia específicos del dominio implementado.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** alto
## Guía para la implementación
El enfoque de decisiones impulsadas por dominio (DDD) es el enfoque fundamental para diseñar y crear software en torno a los dominios empresariales. Resulta útil trabajar con un marco existente a la hora de crear servicios centrados en dominios empresariales. Si trabaja con aplicaciones monolíticas existentes, puede utilizar patrones de descomposición que ofrecen técnicas establecidas para modernizar las aplicaciones y convertirlas en servicios.
![\[Diagrama de flujo que muestra el enfoque de decisiones basadas en el dominio.\]](http://docs.aws.amazon.com/es_es/wellarchitected/latest/reliability-pillar/images/domain-driven-decision.png)
## Pasos para la implementación
+ Los equipos pueden organizar talleres de [tormentas de eventos](https://serverlessland.com/event-driven-architecture/visuals/event-storming) para identificar rápidamente eventos, comandos, agregados y dominios en un formato de notas adhesivas más ligero.
+ Cuando las entidades y funciones del dominio se formen en un contexto de dominio, puede dividir el dominio en servicios mediante un [contexto delimitado](https://martinfowler.com/bliki/BoundedContext.html), en el que se agrupan las entidades que comparten características y atributos similares. Si el modelo está dividido en contextos, tendrá una plantilla para limitar los microservicios.
+ Por ejemplo, las entidades del sitio web de Amazon.com podrían incluir el empaquetado, la entrega, la programación, el precio, el descuento y la divisa.
+ El empaquetado, la entrega y la programación se agrupan en el contexto del envío, mientras que el precio, el descuento y la divisa se agrupan en el contexto de los precios.
+ La [descomposición de los monolitos en microservicios](https://docs.aws.amazon.com/prescriptive-guidance/latest/modernization-decomposing-monoliths/welcome.html) describe los patrones para refactorizar los microservicios. El uso de patrones de descomposición por capacidad empresarial, subdominio o transacción se ajusta bien a los enfoques basados en dominios.
+ Técnicas tácticas como el [contexto burbuja](https://www.domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf), que permiten introducir DDD en aplicaciones existentes o heredadas sin necesidad de reescrituras iniciales ni confirmaciones completas de las DDD. En un enfoque con contexto burbuja, se establece un pequeño contexto delimitado mediante una capa de asignación y coordinación de servicios ([capa anticorrupción](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)), que protege el modelo de dominio recién definido de influencias externas.
Después de que los equipos analicen el dominio y definan las entidades y los contratos de servicio, podrán utilizar los servicios de AWS para implementar su diseño basado en dominio como servicios basados en la nube.
+ Para comenzar el desarrollo, defina pruebas en las que se utilicen las reglas empresariales de su dominio. El desarrollo basado en pruebas (TDD) y el desarrollo basado en comportamiento (BDD) ayudan a los equipos a mantener los servicios centrados en resolver problemas empresariales.
+ Seleccione los [servicios de AWS](https://aws.amazon.com/microservices/) que mejor se adapten a los requisitos del dominio empresarial y a la [arquitectura de microservicios](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html):
+ [AWS sin servidor](https://aws.amazon.com/serverless/) permite a su equipo centrarse en una lógica de dominio específica en lugar de administrar servidores e infraestructuras.
+ Los [contenedores en AWS](https://aws.amazon.com/containers/) simplifican la administración de su infraestructura para que pueda centrarse en los requisitos de su dominio.
+ Las [bases de datos personalizadas](https://aws.amazon.com/products/databases/) le ayudan a adaptar los requisitos de su dominio al tipo de base de datos más adecuado.
+ La [creación de arquitecturas hexagonales en AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html) describe un marco para integrar la lógica empresarial en los servicios que funcionan de manera inversa desde un dominio empresarial para cumplir los requisitos funcionales y, a continuación, asociar los adaptadores de integración. Los patrones que separan los detalles de la interfaz de la lógica empresarial con los servicios de AWS ayudan a los equipos a centrarse en la funcionalidad del dominio y a mejorar la calidad del software.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL03-BP01 Elección de cómo segmentar su carga de trabajo](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP03 Disposición de contratos de servicio por cada API](rel_service_architecture_api_contracts.md)
**Documentos relacionados:**
+ [Microservicios de AWS](https://aws.amazon.com/microservices/)
+ [Implementing Microservices on AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html)
+ [How to break a Monolith into Microservices](https://martinfowler.com/articles/break-monolith-into-microservices.html)
+ [Getting Started with DDD when Surrounded by Legacy Systems](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf)
+ [ Domain-Driven Design: Tackling Complexity in the Heart of Software ](https://www.amazon.com/gp/product/0321125215)
+ [ Building hexagonal architectures on AWS](https://docs.aws.amazon.com/prescriptive-guidance/latest/hexagonal-architectures/welcome.html)
+ [ Decomposing monoliths into 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 Between Bounded Contexts ](https://serverlessland.com/event-driven-architecture/visuals/messages-between-bounded-context)
+ [ Microservices ](https://www.martinfowler.com/articles/microservices.html)
+ [ Desarrollo guiado por pruebas ](https://en.wikipedia.org/wiki/Test-driven_development)
+ [ Desarrollo guiado por comportamiento ](https://en.wikipedia.org/wiki/Behavior-driven_development)
**Ejemplos relacionados:**
+ [ Designing Cloud Native Microservices on AWS (from DDD/EventStormingWorkshop) ](https://github.com/aws-samples/designing-cloud-native-microservices-on-aws/tree/main)
**Herramientas relacionadas:**
+ [Bases de datos en la nube de Nube de AWS](https://aws.amazon.com/products/databases/)
+ [ Sin servidor en AWS](https://aws.amazon.com/serverless/)
+ [ Contenedores en AWS](https://aws.amazon.com/containers/)
# REL03-BP03 Disposición de contratos de servicio por cada API
Los contratos de servicio son acuerdos documentados entre los productores y los consumidores de las API que se encuentran en una definición de API legible por máquina. Una estrategia de control de versiones permite a los clientes seguir usando la API existente y migrar sus aplicaciones a la nueva API cuando estén listas. La implementación del productor puede efectuarse en cualquier momento, siempre y cuando se cumpla el contrato. Los equipos del servicio pueden usar la pila tecnológica que prefieran para cumplir el contrato de la API.
**Resultado deseado:** las aplicaciones creadas con arquitecturas orientadas a servicios o de microservicios pueden funcionar de forma independiente y, al mismo tiempo, tener integrada una dependencia de la versión en tiempo de ejecución. Los cambios implementados en un consumidor o productor de API no interrumpen la estabilidad del sistema general cuando ambas partes utilizan el mismo contrato de API. Los componentes que se comunican a través de las API de servicio pueden llevar a cabo lanzamientos funcionales independientes, actualizar las dependencias en tiempo de ejecución o efectuar conmutaciones por error a un sitio de recuperación de desastres (DR) con poco o ningún impacto entre sí. Además, los servicios discretos pueden escalarse de forma independiente y absorber la demanda de recursos sin que sea necesario que otros servicios se escalen al unísono.
**Patrones comunes de uso no recomendados:**
+ Crear API de servicio sin esquemas estrictamente asignados. Como consecuencia, las API no se pueden usar para generar enlaces de API y las cargas útiles no se pueden validar mediante programación.
+ No adoptar una estrategia de control de versiones, lo que obliga a los usuarios de la API a actualizarla y lanzarla; de lo contrario, fallará cuando los contratos de servicio evolucionen.
+ Mensajes de error que filtran detalles de la implementación del servicio subyacente en lugar de describir los errores de integración en el contexto y el lenguaje del dominio.
+ No utilizar contratos de API para desarrollar casos de prueba ni simulaciones de implementaciones de API para probar de forma independiente los componentes del servicio.
**Beneficios de establecer esta práctica recomendada:** los sistemas distribuidos que constan de componentes que se comunican a través de contratos de servicio de API pueden mejorar la fiabilidad. Los desarrolladores pueden detectar posibles problemas al principio del proceso de desarrollo mediante la comprobación de tipos durante la compilación para comprobar que las solicitudes y las respuestas cumplan el contrato de la API y que los campos obligatorios estén presentes. Los contratos de la API proporcionan una interfaz clara y autodocumentada para las API y mejoran la interoperabilidad entre diferentes sistemas y lenguajes de programación.
**Nivel de riesgo expuesto si no se establece esta práctica recomendada:** medio
## Guía para la implementación
Una vez que hayan identificado los dominios empresariales y determinado la segmentación de la carga de trabajo, podrá desarrollar las API de sus servicios. Primero, defina contratos de servicio legibles por máquina para las API y, a continuación, implemente una estrategia de control de versiones de API. Cuando lo tenga todo preparado para integrar servicios a través de protocolos comunes, como REST, GraphQL o eventos asíncronos, podrá incorporar servicios de AWS a su arquitectura para integrar sus componentes con contratos de API estrictamente asignados.
**Servicios de AWS para contratos de API de servicios**
Incorpore servicios de AWS como [Amazon API Gateway](https://aws.amazon.com/api-gateway/), [AWS AppSync](https://aws.amazon.com/appsync/) y [Amazon EventBridge](https://aws.amazon.com/eventbridge/) a su arquitectura para utilizar los contratos de servicios de API en su aplicación. Amazon API Gateway le ayuda a integrarse directamente con servicios de AWS nativos y otros servicios web. API Gateway admite el control de versiones y la [especificación de OpenAPI](https://github.com/OAI/OpenAPI-Specification). AWS AppSync es un punto de conexión de [GraphQL](https://graphql.org/) administrado que se configura mediante la definición de un esquema de GraphQL para definir una interfaz de servicio para consultas, mutaciones y suscripciones. Amazon EventBridge utiliza esquemas de eventos para definir eventos y generar enlaces de código para sus eventos.
## Pasos para la implementación
+ Primero, defina un contrato para su API. En un contrato, se expresan las capacidades de una API y se definen objetos y campos de datos estrictamente asignados para la entrada y la salida de la API.
+ Cuando configure las API en API Gateway, puede importar y exportar las especificaciones de OpenAPI para sus puntos de conexión.
+ La [importación de una definición de OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/import-edge-optimized-api.html) simplifica la creación de su API y se puede integrar con la infraestructura de AWS, como herramientas de código (por ejemplo, [AWS Serverless Application Model](https://aws.amazon.com/serverless/sam/) y [AWS Cloud Development Kit (AWS CDK)](https://aws.amazon.com/cdk/)).
+ La [exportación de una definición de API](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-export-api.html) simplifica la integración con las herramientas de prueba de API y proporciona a los consumidores de servicios una especificación de la integración.
+ Puede definir y administrar las API de GraphQL con AWS AppSync mediante la [definición de un archivo de esquema de GraphQL](https://docs.aws.amazon.com/appsync/latest/devguide/designing-your-schema.html) para generar su interfaz de contrato y simplificar la interacción con modelos de REST complejos, múltiples tablas de bases de datos o servicios heredados.
+ Los proyectos de [AWS Amplify](https://aws.amazon.com/amplify/) que están integrados con AWS AppSync generan archivos de consulta de JavaScript estrictamente asignados para usarlos en su aplicación, así como una biblioteca de clientes de AWS AppSync GraphQL para tablas de [Amazon DynamoDB](https://aws.amazon.com/dynamodb/).
+ Cuando se consumen eventos de servicio de Amazon EventBridge, los eventos se ajustan a esquemas que ya existen en el registro de esquemas o que se definen con la especificación de OpenAPI. Si tiene un esquema definido en el registro, también puede generar enlaces de clientes desde el contrato de esquema para integrar el código con los eventos.
+ Amplíe la API o lleve a cabo un control de versiones. Ampliar una API es la opción más sencilla cuando se agregan campos que se pueden configurar con campos opcionales o valores predeterminados para los campos obligatorios.
+ Los contratos basados en JSON para protocolos como REST y GraphQL pueden ser una buena opción para la ampliación del contrato.
+ Los contratos basados en XML para protocolos como SOAP deben probarse con los consumidores de servicios para determinar la viabilidad de la ampliación del contrato.
+ Al llevar a cabo el control de versiones de una API, considere la posibilidad de implementar un control de versiones por proxy en el que se utilice una fachada para admitir las versiones, de modo que la lógica se pueda mantener en una única base de código.
+ Con API Gateway, puede usar [asignaciones de solicitud y respuesta](https://docs.aws.amazon.com/apigateway/latest/developerguide/request-response-data-mappings.html#transforming-request-response-body) para simplificar la absorción de los cambios en los contratos mediante el establecimiento de una fachada que proporcione valores predeterminados para los campos nuevos o para quitar los campos eliminados de una solicitud o respuesta. Con este enfoque, el servicio subyacente puede mantener una única base de código.
## Recursos
**Prácticas recomendadas relacionadas:**
+ [REL03-BP01 Elección de cómo segmentar su carga de trabajo](rel_service_architecture_monolith_soa_microservice.md)
+ [REL03-BP02 Desarrollo de servicios centrados en funcionalidades y dominios empresariales específicos](rel_service_architecture_business_domains.md)
+ [REL04-BP02 Implementación de dependencias con acoplamiento débil](rel_prevent_interaction_failure_loosely_coupled_system.md)
+ [REL05-BP03 Control y limitación de las llamadas de reintento](rel_mitigate_interaction_failure_limit_retries.md)
+ [REL05-BP05 Definición de los tiempos de espera del cliente](rel_mitigate_interaction_failure_client_timeouts.md)
**Documentos relacionados:**
+ [ ¿Qué es una interfaz de programación de aplicaciones (API)? ](https://aws.amazon.com/what-is/api/)
+ [ Implementing Microservices on AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/microservices-on-aws.html)
+ [ Microservice Trade-Offs ](https://martinfowler.com/articles/microservice-trade-offs.html)
+ [ Microservices - a definition of this new architectural term ](https://www.martinfowler.com/articles/microservices.html)
+ [ Microservicios en AWS](https://aws.amazon.com/microservices/)
+ [ Working with API Gateway extensions to OpenAPI ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-swagger-extensions.html)
+ [ OpenAPI-Specification ](https://github.com/OAI/OpenAPI-Specification)
+ [ GraphQL: Schemas and Types ](https://graphql.org/learn/schema/)
+ [ Amazon EventBridge code bindings ](https://docs.aws.amazon.com/eventbridge/latest/userguide/eb-schema-code-bindings.html)
**Ejemplos relacionados:**
+ [ Amazon API Gateway: Configuring a REST API Using OpenAPI ](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html)
+ [ Amazon API Gateway to Amazon DynamoDB CRUD application using OpenAPI ](https://serverlessland.com/patterns/apigw-ddb-openapi-crud?ref=search)
+ [ Modern application integration patterns in a serverless age: API Gateway Service Integration ](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)
+ [ Implementing header-based API Gateway versioning with Amazon CloudFront ](https://aws.amazon.com/blogs/compute/implementing-header-based-api-gateway-versioning-with-amazon-cloudfront/)
+ [AWS AppSync: Building a client application ](https://docs.aws.amazon.com/appsync/latest/devguide/building-a-client-app.html#aws-appsync-building-a-client-app)
**Videos relacionados:**
+ [ Using OpenAPI in AWS SAM to manage API Gateway ](https://www.youtube.com/watch?v=fet3bh0QA80)
**Herramientas relacionadas:**
+ [ Amazon API Gateway ](https://aws.amazon.com/api-gateway/)
+ [AWS AppSync](https://aws.amazon.com/appsync/)
+ [ Amazon EventBridge ](https://aws.amazon.com/eventbridge/)