# REL03-BP02 Desarrollar servicios centrados en funcionalidades y dominios empresariales específicos
<a name="rel_service_architecture_business_domains"></a>

 La arquitectura orientada a servicios (SOA) desarrolla servicios con funciones bien delineadas definidas por necesidades empresariales. Los microservicios utilizan modelos de dominios y un contexto limitado para aplicar una restricción de modo que cada servicio lleve a cabo solo una cosa. Al centrarse en funciones específicas, puede diferenciar los requisitos de fiabilidad de los distintos servicios y dirigir las inversiones con un mayor nivel de especificidad. Tener un problema empresarial conciso y un equipo pequeño asociado a cada servicio también facilita un escalado organizativo más sencillo. 

 A la hora de diseñar una arquitectura de microservicios, resulta útil utilizar un diseño basado en dominio (DDD) para modelar el problema empresarial utilizando entidades. Por ejemplo, para el sitio web de Amazon.com, entre las entidades podrían estar el paquete, la entrega, la programación, el precio, el descuento y la divisa. Posteriormente, el modelo se divide aún más en modelos más pequeños con un [https://martinfowler.com/bliki/BoundedContext.html](https://martinfowler.com/bliki/BoundedContext.html), en el que se agrupan las entidades que comparten características y atributos similares. Así, si usamos como ejemplo Amazon.com, el paquete, la entrega y la programación formarían parte del contexto de envío, y el precio, el descuento y la divisa formarían parte del contexto de precios. Si el modelo está dividido en contextos, aparecerá una plantilla para limitar los microservicios. 

![\[Plantilla modelo para la limitación de microservicios\]](http://docs.aws.amazon.com/es_es/wellarchitected/2022-03-31/framework/images/building-services.png)


 **Nivel de riesgo expuesto si no se establece esta práctica recomendada:** Alto 

## Guía para la implementación
<a name="implementation-guidance"></a>
+  Diseñe su carga de trabajo en función de sus dominios empresariales y la funcionalidad correspondiente. Al centrarse en funciones específicas, puede diferenciar los requisitos de fiabilidad de los distintos servicios y dirigir las inversiones con un mayor nivel de especificidad. Tener un problema empresarial conciso y un equipo pequeño asociado a cada servicio también facilita un escalado organizativo más sencillo. 
  +  Lleve a cabo un análisis del dominio para trazar un diseño basado en dominio (DDD) para su carga de trabajo. Posteriormente, podrá elegir un tipo de arquitectura que se ajuste a las necesidades de su carga de trabajo. 
    +  [Cómo descomponer un sistema monolítico en microservicios](https://martinfowler.com/articles/break-monolith-into-microservices.html) 
    +  [Introducción al DDD en un ambiente lleno de sistemas heredados](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 
    +  [Eric Evans «Domain-Driven Design: Tackling Complexity in the Heart of Software» (Diseño basado en dominios: afrontar la complejidad en el corazón del software)](https://www.amazon.com/gp/product/0321125215) 
    +  [Implementación de microservicios en AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+ Descomponga sus servicios en los componentes más pequeños posibles. Con la arquitectura de microservicios, puede separar su carga de trabajo en componentes con la funcionalidad mínima para permitir la escalabilidad y la agilidad organizativas. 
  +  Defina la API para la carga de trabajo y sus objetivos de diseño, límites y cualquier otra consideración de uso. 
    +  Defina la API. 
      +  La definición de la API debería permitir el crecimiento y la incorporación de parámetros adicionales. 
    +  Defina las disponibilidades diseñadas. 
      + Su API puede tener múltiples objetivos de diseño para diferentes funciones.
    +  Establezca límites 
      +  Utilice pruebas para definir los límites de sus capacidades de carga de trabajo. 

## Recursos
<a name="resources"></a>

 **Documentos relacionados:** 
+  [Amazon API Gateway: Configuración de una API de REST con OpenAPI](https://docs.aws.amazon.com/apigateway/latest/developerguide/api-gateway-import-api.html) 
+  [Contexto limitado (un patrón central en un diseño basado en dominios)](https://martinfowler.com/bliki/BoundedContext.html) 
+  [Eric Evans «Domain-Driven Design: Tackling Complexity in the Heart of Software» (Diseño basado en dominios: afrontar la complejidad en el corazón del software)](https://www.amazon.com/gp/product/0321125215) 
+  [Introducción al DDD en un ambiente lleno de sistemas heredados](https://domainlanguage.com/wp-content/uploads/2016/04/GettingStartedWithDDDWhenSurroundedByLegacySystemsV1.pdf) 
+  [Cómo descomponer un sistema monolítico en microservicios](https://martinfowler.com/articles/break-monolith-into-microservices.html) 
+  [Implementación de microservicios en AWS](https://docs.aws.amazon.com/whitepapers/latest/microservices-on-aws/introduction.html) 
+  [Compensaciones de los microservicios](https://martinfowler.com/articles/microservice-trade-offs.html) 
+  [Microservicios: definición de este nuevo término de arquitectura](https://www.martinfowler.com/articles/microservices.html) 
+  [Microservicios en AWS](https://aws.amazon.com/microservices/)