Uso del 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. De lo contrario, corre el riesgo de crear un diseño no estructurado que tenga dependencias ocultas entre servicios, acoplamiento estricto 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 límites de servicio es un esfuerzo continuo para desarrollar cargas de trabajo. A veces, la evaluación da como resultado límites redefinidos 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

Diseñe microservicios en torno a las funcionalidades empresariales, no las capas horizontales, como el acceso a datos o la mensajería. Asegúrese de que los microservicios tengan acoplamiento flexible y una cohesión funcional alta. Los microservicios se acoplan de forma flexible si puede cambiar un servicio sin actualizar otros servicios al mismo tiempo. Un microservicio es cohesivo si tiene un único propósito bien definido, como administrar cuentas de usuario o realizar un seguimiento del historial de entrega. Los servicios deben encapsular el conocimiento del dominio y aislar el conocimiento de los clientes. Por ejemplo, un cliente puede programar un dron sin conocer el algoritmo de programación o la administración de flotas de drones.

Debe definir las características de arquitectura de cada microservicio para que coincidan con sus preocupaciones de dominio, en lugar de definirlas para todo el sistema. Por ejemplo, un microservicio orientado al cliente podría requerir rendimiento, disponibilidad, tolerancia a errores, seguridad, capacidad de prueba y agilidad. Un microservicio back-end puede requerir solo tolerancia a errores y seguridad. Cuando los microservicios se comunican sincrónicamente, su dependencia en tiempo de ejecución suele requerir que compartan las mismas características de arquitectura.

El diseño controlado por dominio (DDD) proporciona un marco que admite el diseño de microservicios bien estructurados. DDD tiene una fase estratégica y una fase táctica . En DDD estratégico, se define la estructura del sistema a gran escala. DDD estratégico garantiza que la arquitectura permanece centrada en las funcionalidades empresariales. Tactical DDD proporciona 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 acoplados y cohesivos.

El concepto de lenguaje omnipresente es central en DDD. Es un vocabulario compartido que los desarrolladores y expertos en dominio crean juntos dentro de cada contexto limitado. Los equipos usan este lenguaje de forma coherente en conversaciones, documentación y código. Cuando los mismos términos significan lo mismo en todas estas áreas, los equipos reducen los malentendidos y generan modelos de dominio que reflejan con precisión la intención empresarial. Cada contexto limitado puede tener su propio lenguaje omnipresente, lo que significa que la misma palabra (como cuenta) tiene significados diferentes en contextos diferentes.

En este artículo y el artículo relacionado DDD Táctico se presentan los pasos siguientes y se aplican a la aplicación de entrega con drones.

1. Analice el dominio empresarial para comprender los requisitos funcionales de la aplicación. La salida de este paso es una descripción informal del dominio, que puede refinar en un conjunto más formal de modelos de dominio.

2. Defina los contextos enlazados del dominio. Cada contexto enlazado contiene un modelo de dominio que representa un subdominio específico de la aplicación más grande.

3. Aplique patrones DDD tácticos dentro de un contexto limitado para definir entidades, agregados y servicios de dominio.

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

En este artículo se describen los dos primeros pasos, que se refieren principalmente a DDD estratégico. El artículo DDD táctico trata el paso 3. En el artículo Identificación de los límites de microservicio se describe el paso 4. DDD es un proceso iterativo y continuo, por lo que los límites de servicio no permanecen fijos. A medida que evoluciona una aplicación, puede decidir separar un servicio en varios servicios más pequeños.

Escenario: Drone Delivery

Fabrikam, Inc., inicia un servicio de entrega de drones. La empresa administra una flota de drones. Las empresas se registran con el servicio y los usuarios solicitan un dron para recoger mercancías para su entrega. Cuando un cliente programa una recogida, un sistema back-end asigna un dron y notifica al usuario un tiempo de entrega estimado. Mientras avanza la entrega, el cliente realiza un seguimiento de la ubicación del dron, con una hora estimada de llegada (ETA) actualizada continuamente.

Este escenario implica un dominio complejo. Entre los principales problemas empresariales se incluyen cómo programar drones, realizar un seguimiento de los paquetes, administrar cuentas de usuario y almacenar y analizar datos históricos. Fabrikam también tiene como objetivo llegar al mercado rápidamente e iterar rápidamente para agregar nuevas funcionalidades y capacidades. La aplicación debe funcionar a escala en la nube y cumplir un objetivo de alto nivel de servicio (SLO). Fabrikam también espera que diferentes partes del sistema tengan requisitos diferentes para las operaciones de consulta y almacenamiento de datos. Estas consideraciones llevan a Fabrikam a adoptar una arquitectura de microservicios para la aplicación de entrega de drones.

Análisis del dominio

Un enfoque DDD le ayuda a diseñar microservicios para que cada servicio se alinee de forma natural con un requisito empresarial funcional. También le ayuda a evitar permitir que los límites de la organización o las opciones tecnológicas dictan su diseño.

Antes de escribir cualquier código, necesita una comprensión general del sistema que cree. DDD modela el dominio empresarial y crea un modelo de dominio. El modelo de dominio es un modelo abstracto del ámbito empresarial. Destila y organiza el conocimiento del dominio y establece un lenguaje compartido para desarrolladores y expertos en dominios.

Empiece por asignar todas las funciones empresariales y las conexiones entre ellas. Este esfuerzo debe implicar a expertos en dominios, arquitectos de software y otras partes interesadas. No es necesario seguir un método formal específico. Por ejemplo, puede dibujar un diagrama o usar una pizarra. Un enfoque estructurado implica la tormenta de eventos. Ya sea que utilice event storming o un enfoque menos formal, el objetivo es crear una comprensión compartida del dominio antes de elegir las tecnologías.

Al rellenar el diagrama, es posible que empiece a identificar subdominios discretos. Busque los siguientes patrones:

• Funciones que están estrechamente relacionadas

• Funciones que son clave para la empresa frente a funciones que proporcionan servicios auxiliares

• Gráfico de dependencias entre funciones

Durante esta fase inicial, no se centre en tecnologías ni detalles de implementación. Pero debe identificar dónde debe integrarse la aplicación 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 de dominio inicial, el equipo de Fabrikam crea un boceto aproximado que representa el dominio de entrega de drones.

• El envío aparece en el centro del diagrama porque es fundamental para la empresa. Todo lo demás del diagrama existe para admitir esta funcionalidad.

• El elemento Drone management (administración de drones) también es esencial para la empresa. La funcionalidad estrechamente relacionada con la administración de drones incluye la reparación de drones y el uso de análisis predictivo para predecir cuándo los drones necesitan mantenimiento y mantenimiento.

• Análisis de ETA proporciona estimaciones de tiempo para la recogida y la entrega.

• El transporte de terceros permite a la aplicación programar métodos de transporte alternativos si un paquete no se puede enviar completamente mediante dron.

• 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 horas específicas y puede alquilar drones inactivos. La versión inicial no incluye esta característica.

• La funcionalidad Video surveillance (vigilancia por vídeo) es otra área que la empresa podría expandir en versiones posteriores.

• Las cuentas de usuario, la facturación y el centro de llamadas son subdominios que admiten el negocio principal.

DDD clasifica subdominios en tres categorías y esta clasificación ayuda a priorizar dónde invertir el mayor esfuerzo de diseño:

• Los subdominios principales proporcionan una ventaja competitiva. El envío y la administración de drones forman subdominios principales para Fabrikam porque definen la empresa. Estos subdominios requieren un modelado detallado y una inversión sustancial en equipo.

• Los subdominios auxiliares mantienen el funcionamiento empresarial, pero no lo diferencian de los competidores. La facturación se incluye en esta categoría. Requiere desarrollo personalizado, pero no sirve como origen de ventaja competitiva.

• Los subdominios genéricos representan problemas que el sector ya ha resuelto. Las cuentas de usuario y los subdominios genéricos del centro de llamadas que Fabrikam pueden abordar mediante soluciones precompiladas o estándar existentes en lugar de sistemas personalizados.

En este momento del proceso, Fabrikam no ha tomado ninguna decisión sobre la implementación ni las tecnologías. Algunos de los subsistemas pueden implicar sistemas de software externos o servicios que no son de Microsoft. Pero la aplicación debe interactuar con estos sistemas y servicios, por lo que Fabrikam los incluye en el modelo de dominio.

Definición de contextos delimitados

El modelo de dominio incluye representaciones de entidades reales, como usuarios, drones, paquetes y otras entidades. Pero eso no significa que cada parte del sistema necesite usar las mismas representaciones para las mismas entidades.

Por ejemplo, los subsistemas que controlan la reparación de drones y el análisis predictivo deben 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 llegue el momento de programar una entrega, esos detalles serán irrelevantes. El subsistema de programación solo necesita saber si un dron está disponible y el ETA para recogida y entrega.

La creación de un único modelo para ambos subsistemas presenta una complejidad innecesaria. El modelo también es más difícil de evolucionar con el tiempo, ya que los cambios necesitan satisfacer varios equipos que trabajan en subsistemas independientes. Como resultado, es mejor diseñar modelos independientes que representen la misma entidad real (en este caso, un dron) en dos contextos diferentes. Cada modelo incluye solo las características y atributos que son relevantes en su contexto.

El concepto DDD de contextos enlazados se aplica aquí. Un contexto enlazado define el límite dentro de un dominio donde se aplica un modelo de dominio específico. Fabrikam puede agrupar la funcionalidad en función de si las distintas funciones comparten el mismo modelo de dominio.

Los contextos enlazados no están necesariamente aislados entre sí. En el diagrama anterior, las líneas sólidas que conectan los contextos enlazados representan lugares donde interactúan dos contextos enlazados. Por ejemplo, el envío depende de las cuentas de usuario para recuperar la información del cliente y de la gestión de drones para programar las unidades de la flota.

Fabrikam identifica estas interacciones y crea un mapa de contexto que documenta las relaciones entre contextos enlazados. Un mapa de contexto resalta los puntos de integración y ayuda a los equipos a aclarar las responsabilidades. Evans y los profesionales de DDD posteriores describen varios patrones de relación:

• Customer-Supplier: un contexto (ascendente) proporciona datos o servicios de los que depende otro contexto (descendente). Los equipos negocian el contrato entre ellos.

• Open Host Service y Published Language: El contexto ascendente expone una API bien definida (Servicio de Anfitrión Abierto) descrita en un formato compartido (Idioma Publicado) que consumen los contextos descendentes.

• Capa anticorrupción: el equipo descendente crea una capa de traducción para proteger su modelo frente a los cambios del modelo ascendente.

• Caminos separados: dos contextos no tienen integración. Cada contexto evoluciona de forma independiente.

En una arquitectura de microservicios, Open Host Service y Published Language son especialmente relevantes porque los microservicios se comunican a través de API bien definidas. En el artículo Diseño de API para microservicios se describe cómo usar la especificación openAPI para definir descripciones de interfaz independiente del lenguaje para las API REST, expresadas en formato JSON o YAML.

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

Paso siguiente

Después de completar un análisis de dominio, aplique DDD táctico para definir los modelos de dominio de forma más precisa.

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