Análisis de una aplicación e identificación de los límites de la descomposición

Completado

Para trasladar su aplicación a una arquitectura de microservicios, Fabrikam debe evaluar la aplicación actual y determinar el ámbito y el límite de cada microservicio. Para esta evaluación, van a usar el marco de trabajo de diseño basado en dominios (DDD). A continuación, se verá cómo lo implementan en su aplicación.

Nota

Este artículo no muestra un análisis de dominio completo y minucioso. El ejemplo es breve de forma deliberada para ilustrar los puntos principales. Para más información sobre DDD, vea la sección "Más información" en el resumen al final de este módulo.

¿Qué es el diseño basado en dominios?

DDD es un enfoque de diseño de sistemas introducido originalmente por Erik Evans en el libro de 2005 Domain-Driven Design: Tackling Complexity in the Heart of Software (Diseño basado en dominios: Abordar la complejidad en el corazón del software). Este enfoque incluye tres elementos clave:

• Centrarse en el dominio principal y la lógica del dominio.
• Estructurar el diseño en un modelo del dominio.
• Impulsar la colaboración iterativa entre los equipos técnicos y los asociados empresariales para mejorar el sistema de forma constante.

DDD proporciona un marco que puede ayudarle en gran medida a obtener un conjunto de microservicios bien diseñados. Tiene dos fases distintas, la estratégica y la táctica. En el diseño basado en dominios estratégico, se define la estructura a gran escala del sistema. Ayuda a garantizar que la arquitectura permanece centrada en las funcionalidades del negocio. El diseño basado en dominios táctico proporciona un conjunto de modelos de diseño que puede usar para crear el modelo de dominio. Estos modelos incluyen entidades, agregados y servicios de dominio. Estos modelos tácticos ayudan a diseñar microservicios coherentes y con acoplamiento flexible.

Durante la fase estratégica del diseño basado en dominios, se asigna el dominio empresarial y se definen los contextos delimitados para los modelos de dominio. El diseño basado en dominios táctico consiste en definir los modelos de dominio con más precisión. Los patrones tácticos se aplican dentro de un único contexto delimitado. En una arquitectura de microservicios, interesan los patrones de agregados y entidades. La aplicación de estos patrones ayuda a identificar los límites naturales de los servicios de la aplicación. Como principio general, un microservicio no debe ser menor que un agregado ni mayor que un contexto delimitado.

En un nivel general, este proceso se puede dividir en cuatro pasos:

1. 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 se puede refinar en un conjunto más formal de modelos de dominio.
2. Definir 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. Identificar los microservicios de la aplicación mediante los resultados del paso anterior.

Se examinará con más detalle lo que sucede en cada uno de estos pasos.

Análisis del dominio empresarial

Con el diseño basado en dominios, se empieza por modelar el dominio empresarial y se crea un modelo de dominio. El modelo de dominio es un modelo abstracto del dominio empresarial. Extrae y organiza el conocimiento del dominio, y proporciona un lenguaje común para los desarrolladores y los expertos en los dominios.

Empiece por asignar todas las funciones empresariales y sus conexiones. Este análisis es un esfuerzo colaborativo que implica a expertos en dominios, arquitectos de software y otras partes interesadas. No es necesario usar ningún formalismo concreto. Esboce un diagrama o dibújelo en una pizarra.

A medida que rellene el diagrama, es posible que empiece a identificar subdominios discretos. ¿Qué funciones están estrechamente relacionadas? ¿Cuáles son fundamentales para la empresa y cuáles 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. Es decir, debe tener en cuenta el lugar donde la aplicación se debe integrar con sistemas externos, como CRM, sistemas de facturación o de procesamiento de pagos.

Definición de contextos delimitados

El modelo de dominio incluye representaciones de cosas reales del mundo, como usuarios, drones y paquetes. Pero eso no significa que todos los elementos 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 tienen que representar muchas características físicas de los drones. Estas características incluyen el historial de mantenimiento, el kilometraje, la antigüedad, el número de modelo y los detalles de rendimiento. Pero, cuando llega el momento de programar una entrega, esos elementos no importan. El subsistema de programación solo necesita saber si un dron está disponible y el tiempo estimado de llegada (ETA) para la recogida y la entrega.

Si se intenta crear un modelo único para ambos subsistemas, resulta más complejo de lo necesario. También resulta más difícil para el modelo evolucionar con el tiempo, porque los cambios deben satisfacer a varios equipos que trabajen en subsistemas independientes. 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.

Este enfoque es donde entra en juego el concepto del diseño basado en dominios referente a los contextos delimitados. Un contexto delimitado es simplemente el límite dentro de un dominio donde se aplica un modelo de dominio concreto. Si se examina el diagrama anterior, se puede agrupar la funcionalidad en función de si varias funciones comparten un único modelo de dominio.

Definición de entidades, agregados y servicios

El diseño basado en dominios táctico consiste en definir los modelos de dominio con más precisión. Los patrones tácticos se aplican dentro de un único contexto delimitado. En una arquitectura de microservicios, interesan los patrones de agregados y entidades. La aplicación de estos patrones ayuda a identificar los límites naturales de los servicios de la aplicación. Como principio general, un microservicio no debe ser menor que un agregado ni mayor que un contexto delimitado.

Hay varios patrones de diseño basado en dominios táctico que se deben tener en cuenta:

• Entidades: una entidad es un objeto con una identidad única que persiste en el tiempo. Por ejemplo, en una aplicación bancaria, las cuentas y los clientes son entidades.
• Objetos de valor: Un objeto de valor no tiene identidad. Los valores de sus atributos lo definen y es inmutable. Ejemplos típicos de objetos de valor son los colores, las fechas y horas, y los valores de divisa.
• Agregados: un agregado define un límite de coherencia alrededor de una o varias entidades. El propósito de un agregado es modelar los elementos invariables transaccionales. Las cosas en el mundo real tienen redes complejas de relaciones. Los clientes crean pedidos, los pedidos contienen productos, los productos tienen proveedores y así sucesivamente. Si la aplicación modifica varios objetos relacionados, ¿cómo podemos garantizar la coherencia? ¿Cómo se realiza el seguimiento de los elementos invariables y cómo se aplican?
• Servicios de aplicación y de dominio: En la terminología del diseño basado en dominios, un servicio es un objeto que implementa alguna lógica sin mantener ningún estado. Evans distingue entre los servicios de dominio, que encapsulan la lógica de dominio y los servicios de aplicación, que proporcionan funcionalidad técnica. Normalmente, los servicios de aplicación incluyen funcionalidad técnica, como la autenticación de usuario o el envío de un mensaje SMS. Los servicios de dominio a menudo se usan para modelar el comportamiento que abarca varias entidades.
• Eventos de dominio: Los eventos de dominio se pueden usar para notificar a otras partes del sistema cuando sucede algo. Como sugiere su nombre, los eventos de dominio deben significar algo dentro del dominio. Por ejemplo, "se inserta un registro en una tabla" no es un evento de dominio. "Se ha cancelado una entrega" es un evento de dominio. Los eventos de dominio son especialmente importantes en una arquitectura de microservicios. Dado que los microservicios se distribuyen y no comparten los almacenes de datos, los eventos de dominio proporcionan una manera de que los microservicios se coordinen entre sí.

En su sistema, el equipo de desarrollo de Fabrikam ha identificado las entidades siguientes:

• Entrega
• Paquete
• Dron
• Cuenta
• Confirmación
• Notificación
• Etiqueta

Las cuatro primeras entidades (entrega, paquete, dron y cuenta) son agregados que representan los límites de la coherencia transaccional. Las confirmaciones y las notificaciones son entidades secundarias de las entregas. Las etiquetas son entidades secundarias de los paquetes.

Los objetos de valor de este diseño incluyen la ubicación (Location), el tiempo estimado (ETA), el peso del paquete (PackageWeight) y el tamaño (PackageSize).

Hay dos eventos de dominio:

• Mientras un dron está volando, la entidad de dron (Drone) envía eventos DroneStatus que describen la ubicación y el estado del dron, por ejemplo, en vuelo o en tierra.
• La entidad de entrega (Delivery) envía eventos de seguimiento de la entrega (DeliveryTracking) cada vez que cambia la fase de una entrega. Estos eventos incluyen DeliveryCreated, DeliveryRescheduled, DeliveryHeadedToDropoff y DeliveryCompleted.

Tenga en cuenta que estos eventos describen aspectos significativos dentro del modelo de dominio. Describen algo sobre el dominio y no están vinculados a una construcción de un lenguaje de programación determinado.

El equipo de desarrollo ha identificado un área más de funcionalidad, que no encaja claramente en ninguna de las entidades descritas hasta ahora. Una parte del sistema debe coordinar todos los pasos implicados en la programación o actualización de una entrega. El equipo de desarrollo ha agregado dos servicios de dominio al diseño. Un Programador coordina los pasos. Un Supervisor supervisa el estado de cada paso, con el fin de detectar si se ha producido un error en alguno de los pasos o se ha agotado el tiempo de espera.

Identificación de los microservicios

Ahora está preparado para pasar del modelo de dominio al diseño de la aplicación. Este es un enfoque que puede usar para derivar microservicios desde el modelo de dominio.

1. Comience con un contexto delimitado. En general, la funcionalidad de un microservicio no debería abarcar más de un contexto enlazado. Por definición, un contexto delimitado marca el límite de un modelo de dominio en particular. Si el microservicio combina diferentes modelos de dominio, es un signo de que es posible que tenga que refinar el análisis de dominio.
2. A continuación, mire los agregados en el modelo de dominio. Los agregados suelen ser buenos candidatos para microservicios. Un agregado bien diseñado tiene muchas de las características de un microservicio bien diseñado:
   • Un agregado se deriva de los requisitos empresariales más que de las preocupaciones técnicas, como el acceso a datos o la mensajería.
   • Un agregado debe tener una cohesión funcional alta.
   • Un agregado es un límite de persistencia.
   • Los agregados deben tener un acoplamiento flexible.
3. Los servicios de dominio también son buenos candidatos para microservicios. Los servicios de dominio son operaciones sin estado a través de varios agregados. Un ejemplo típico es un flujo de trabajo que implica varios microservicios. Más adelante, vemos un ejemplo de un servicio de dominio en la aplicación Drone Delivery.
4. Por último, tenga en cuenta los requisitos no funcionales. Observe factores como el tamaño del equipo, los tipos de datos, tecnologías, requisitos de escalabilidad, requisitos de disponibilidad y requisitos de seguridad. Es posible que estos factores le lleven a dividir aún más un microservicio en dos o más servicios más pequeños, o bien a hacer lo contrario mediante la combinación de varios microservicios en uno.

Es importante ser pragmático y recordar que el diseño basado en dominios es un proceso iterativo. En caso de duda, empiece con microservicios más generales. Es más sencillo dividir un microservicio en dos servicios más pequeños que refactorizar la funcionalidad entre varios microservicios existentes.

Aplicación del diseño basado en dominios a la aplicación de drones

En el caso de la aplicación de Fabrikam, todos estos servicios residen en su aplicación monolítica existente. Ahora que han identificado dónde descomponer su aplicación en microservicios, van a empezar con el servicio de paquetería.

En la actualidad, el servicio de paquetería tiene un equipo de desarrollo dedicado, ha mostrado problemas de rendimiento relacionados con la escalabilidad y es un excelente candidato para comenzar la descomposición de la aplicación.