Uso de análisis de dominios para modelar microservicios

Uno de los mayores desafíos de los microservicios es definir los límites de los servicios individuales. La regla general es que un servicio debe hacer solo una cosa, pero poner esa regla en práctica requiere un pensamiento cuidadoso. No hay ningún proceso mecánico que genere el diseño correcto. Debe pensar profundamente en su dominio empresarial, requisitos, características de arquitectura (también conocidos como requisitos no funcionales) y objetivos. En caso contrario, puede terminar con un diseño incoherente que exhiba algunas características no deseables, como son dependencias ocultas entre servicios, un acoplamiento rígido o interfaces mal diseñadas. En este artículo se muestra un enfoque basado en dominios para el diseño de los microservicios. La evaluación de los límites de servicio es un esfuerzo continuo en la evolución de las cargas de trabajo. A veces, la evaluación da como resultado definiciones redefinidas de los límites existentes que requieren más desarrollo de aplicaciones para dar cabida a los cambios.

En este artículo se usa un servicio de entrega con drones como ejemplo de ejecución. Para obtener más información sobre el escenario y la implementación de referencia correspondiente, consulte Diseño de una arquitectura de microservicios.

Introducción

Los microservicios deben diseñarse alrededor de las funcionalidades de la empresa, no en capas horizontales como el acceso a datos o la mensajería. Además, deben tener un acoplamiento flexible y una alta cohesión funcional. Los microservicios exhiben un acoplamiento flexible si puede cambiar un servicio sin necesidad de que los demás se actualicen al mismo tiempo. Un microservicio es coherente si tiene un propósito único y bien definido, como administrar las cuentas de usuario o realizar el seguimiento del historial de entregas. Un servicio debe encapsular el conocimiento del dominio y abstraer ese conocimiento ante los clientes. Por ejemplo, un cliente debe poder programar un dron sin conocer los detalles sobre el algoritmo de programación y el modo en que la flota de drones se administra. Las características de arquitectura deben definirse para que cada microservicio coincida con sus preocupaciones de dominio, en lugar de definirse para todo el sistema. Por ejemplo, un microservicio orientado al cliente podría necesitar tener rendimiento, disponibilidad, tolerancia a errores, seguridad, capacidad de prueba y agilidad. Es posible que un microservicio back-end tenga que tener solo tolerancia a errores y seguridad. Si los microservicios tienen comunicaciones sincrónicas entre sí, la dependencia entre ellos suele producir la necesidad de compartir las mismas características de arquitectura.

El diseño basado en dominios (DDD) proporciona una plataforma que puede ayudarle en gran medida a diseñar bien los microservicios. DDD tiene dos fases distintas, estratégicas y tácticas. En DDD estratégico, se define la estructura a gran escala del sistema. El DDD estratégico ayuda a garantizar que la arquitectura permanezca centrada en las capacidades de negocio. DDD táctico proporciona un conjunto de patrones de diseño que puede usar para crear el modelo de dominio. Estos modelos incluyen entidades, agregados y servicios de dominio. Estos patrones tácticos le ayudan a diseñar microservicios que se acoplan de forma flexible y cohesiva.

En este artículo y en el siguiente, usaremos los siguientes pasos, que aplicaremos a la aplicación Drone Delivery:

1. Empiece por analizar el dominio de la empresa para conocer los requisitos funcionales de la aplicación. El resultado de este paso es una descripción informal del dominio, que puede perfilarse en un conjunto más formal de modelos de dominio.

2. A continuación, defina los contextos delimitados del dominio. Cada contexto delimitado contiene un modelo de dominio que representa un subdominio concreto de la aplicación mayor.

3. Dentro de un contexto delimitado, se aplican los modelos tácticos de diseño basado en dominios para definir las entidades, los agregados y los servicios de dominio.

4. Use los resultados del paso anterior para identificar los microservicios de la aplicación.

En este artículo, abordamos los tres primeros pasos, que están relacionados principalmente con el Diseño Guiado por el Dominio. En el próximo artículo, se identificarán los microservicios. Sin embargo, es importante recordar que el diseño basado en dominios es un proceso iterativo y en curso. Los límites del servicio no son fijos. A medida que evoluciona una aplicación, puede decidir dividir un servicio en varios servicios más pequeños.

Escenario: Drone Delivery

Fabrikam, Inc. está iniciando un servicio de entrega con drones. La empresa administra una flota de drones. Las empresas se registran en el servicio y los usuarios pueden solicitar que un dron recoja los bienes para la entrega. Cuando un cliente programa una recogida, un sistema back-end asigna un dron y notifica al usuario con un tiempo de entrega estimado. Mientras la entrega esté en curso, el cliente puede seguir la ubicación del dron, con una hora de llegada estimada que se actualiza constantemente.

Este escenario incluye un dominio bastante complejo. Algunas de las principales preocupaciones empresariales incluyen la programación de drones, los paquetes de seguimiento, la administración de cuentas de usuario y el almacenamiento y el análisis de datos históricos. Fabrikam también tiene como objetivo llegar al mercado rápidamente e iterar con agilidad, añadiendo nuevas funcionalidades y capacidades. La aplicación debe funcionar a escala en la nube y cumplir un objetivo de alto nivel de servicio. Además, Fabrikam espera que diferentes partes del sistema tengan distintos requisitos para el almacenamiento de datos y la consulta. Estas consideraciones llevan a Fabrikam a adoptar una arquitectura de microservicios para la aplicación Drone Delivery.

Análisis del dominio

Un enfoque DDD le ayuda a diseñar microservicios para que cada servicio forme un ajuste natural a un requisito empresarial funcional. Puede servirle de ayuda para evitar la trampa que supone permitir que los límites de la organización o las elecciones de tecnología dicten el diseño.

Antes de escribir cualquier código, debe tener una comprensión general del sistema que compile. DDD comienza modelando el dominio empresarial y creando un modelo de dominio. El modelo de dominio es un modelo abstracto del ámbito empresarial. Destila y organiza el conocimiento de dominio y proporciona un lenguaje común para desarrolladores y expertos en dominios.

Empiece por asignar todas las funciones empresariales y sus conexiones. Este esfuerzo puede ser una colaboración que incluya expertos en dominios, arquitectos de software y otras partes interesadas. No es necesario usar ningún formalismo concreto. Esboce un diagrama o dibuje en una pizarra.

Al rellenar el diagrama, es posible que empiece a identificar subdominios discretos. ¿Qué funciones están estrechamente relacionadas? ¿Qué funciones son fundamentales para la empresa y qué funciones proporcionan servicios auxiliares? ¿Cuál es el gráfico de dependencias? Durante esta fase inicial, no se preocupe de las tecnologías ni de los detalles de implementación. Dicho esto, debe tener en cuenta el lugar donde la aplicación debe integrarse con sistemas externos, como la administración de relaciones con el cliente, el procesamiento de pagos o los sistemas de facturación.

Ejemplo: Aplicación Drone Delivery

Después de un análisis inicial del dominio, el equipo de Fabrikam elaboró un esbozo que representa el dominio de Entrega con Drones.

• El elemento Shipping (envío) se coloca en el centro del diagrama, ya que es importante para el negocio. Todo lo demás dentro del diagrama existe para habilitar esta funcionalidad.
• El elemento Drone management (administración de drones) también es esencial para la empresa. La funcionalidad que está estrechamente relacionada con la anterior es Drone repair (reparación de drones) y el uso de predictive analysis (análisis predictivos) que permiten predecir el momento en que los drones tienen que someterse a tareas de mantenimiento.
• Análisis de ETA proporciona estimaciones de tiempo para la recogida y la entrega.
• La funcionalidad Third-party transportation (transporte de terceros) permitirá que la aplicación programe métodos de transporte alternativo, si un dron no puede entregar un paquete completo.
• La funcionalidad Drone sharing (uso compartido de drones) es una posible extensión del negocio principal. Es posible que la empresa tenga una capacidad excesiva de drones durante determinadas horas y podría alquilar drones que, de lo contrario, estarían inactivos. Esta característica no estará en la versión inicial.
• La funcionalidad Video surveillance (vigilancia por vídeo) es otra área que la empresa podría expandir en versiones posteriores.
• User accounts (cuentas de usuario), Invoicing (facturación) y Call center (centro de llamadas) son subdominios que contribuyen al negocio principal.

Tenga en cuenta que, en este punto del proceso, no hemos tomado decisiones sobre la implementación o las tecnologías. Algunos de los subsistemas pueden implicar sistemas de software externos o servicios de terceros. Aun así, la aplicación requiere interactuar con estos sistemas y servicios, por lo que es importante incluirlos en el modelo de dominio.

Definición de contextos delimitados

El modelo de dominio incluirá representaciones de cosas reales del mundo, como usuarios, drones, paquetes, etc. Pero eso no significa que todas las partes del sistema deban usar las mismas representaciones para las mismas cosas.

Por ejemplo, los subsistemas que controlan la reparación de drones y el análisis predictivo deberán representar muchas características físicas de los drones, como su historial de mantenimiento, kilometraje, antigüedad, número de modelo y características de rendimiento. Pero, cuando llega el momento de programar una entrega, no importan esos elementos. El subsistema de programación solo necesita saber si un dron está disponible y el tiempo estimado para la recogida y la entrega.

Si se ha intentado crear un modelo único para ambos subsistemas, sería innecesariamente complejo. También resultaría más difícil para el modelo evolucionar con el tiempo, porque los cambios deberán satisfacer a varios equipos que trabajen en subsistemas independientes. Por lo tanto, a menudo es mejor diseñar modelos independientes que representen la misma entidad del mundo real (en este caso, un dron) en dos contextos diferentes. Cada modelo contiene solo las características y los atributos que sean pertinentes en su contexto determinado.

El concepto DDD de contextos limitados entra en juego aquí. Un contexto enlazado define el límite dentro de un dominio donde se aplica un modelo de dominio específico. Al hacer referencia al diagrama anterior, puede agrupar la funcionalidad en función de si las distintas funciones comparten el mismo modelo de dominio.

Los contextos delimitados no están necesariamente aislados entre sí. En este diagrama, las líneas continuas que conectan los contextos delimitados representan los lugares donde dos de ellos interactúan. Por ejemplo, el envío depende de las cuentas de usuario para obtener información sobre los clientes y de la gestión de drones para programar los drones de la flota.

En el libro Domain Driven Design de Eric Evans, se describen varios patrones para mantener la integridad de un modelo de dominio cuando interactúa con otro contexto delimitado. Uno de los principios fundamentales de los microservicios es que los servicios se comunican a través de API bien definidas. Este método se corresponde con dos patrones que Evans llama Open Host Service (servicio de host abierto) y Published Language (lenguaje publicado). La idea subyacente en Open Host Service es que un subsistema define un protocolo formal (API) para que otros se comuniquen con él. Published Language amplía esta idea publicando la API de forma que otros equipos puedan usarla para escribir clientes. En el artículo Diseño de API para microservicios, se trata el uso de OpenAPI Specification (Especificación de OpenAPI), conocida anteriormente como Swagger, para definir las descripciones de la interfaz independiente del lenguaje para las API de REST, expresadas en formato JSON o YAML.

En el resto de este viaje, nos centraremos en el contexto delimitado del envío.

Pasos siguientes

Después de completar un análisis de dominio, el siguiente paso es aplicar el diseño basado en dominios táctico para definir los modelos de dominio con más precisión.

Recursos relacionados

• Diseño de arquitectura de microservicios
• Diseño de una arquitectura de microservicios
• Identificación de los límites de los microservicios
• Elección de una opción de proceso de Azure para los microservicios