diagrama de casos de uso para microservicios

¿Qué debe hacer cuando sus microservicios comiencen a "hablar con sus propias palabras"?

Imagínese: tiene un proyecto muy complejo entre manos, una arquitectura de microservicio, suena muy sofisticada, ¿verdad? Cada servicio es bastante capaz, pero ¿juntos? La comunicación es como una conferencia internacional sin intérprete. El servicio B no pudo comprender los datos generados por el servicio A; El servicio C envió un comando, pero el servicio D no respondió durante mucho tiempo. A medida que pasa el tiempo, descubrirá que puede dedicar más tiempo a depurar y hacer que estos servicios "se entiendan entre sí" que a desarrollar la funcionalidad en sí.

Esta pregunta es bastante común ¿verdad? A menudo nos centramos en hacer que cada servicio sea perfecto, pero nos olvidamos de diseñar un conjunto claro de "reglas sociales" para ellos. El resultado es confusión interna, ineficiencia e incluso un freno mutuo.

¿Existe un "mapa" que pueda mostrar claramente desde el principio cómo interactúan estos servicios y a quién sirven? ¿Convertirlo no sólo en un diagrama técnico para los desarrolladores, sino también en un "guión gráfico" que todo el equipo, incluso los amigos que no son tan expertos en tecnología, pueda entender?

¿Puede una imagen hacer que la colaboración ya no sea “adivinable”?

Aquí es donde entra en juego el diagrama de casos de uso para microservicios. No le importa lo que se usa en su código, le importa "quién" (usuario o sistema externo) quiere "hacer" (objetivo) y "cómo" responde su microservicio a esas cosas.

Por ejemplo, un escenario simple de comercio electrónico. El usuario quiere completar el pago. Esta imagen mostrará claramente que el rol de "usuario" desencadena el caso de uso de "pago". Este caso de uso puede estar relacionado con la colaboración entre "servicio de pedidos", "servicio de pago" y "servicio de inventario". De un vistazo, sabrá qué servicios deberían estar involucrados y dónde están sus límites, en lugar de esperar hasta que algo salga mal para determinar de quién es la responsabilidad.

Alguien puede preguntar: "¿Cuál es la diferencia entre este y el diagrama de arquitectura del sistema que dibujamos antes?" Bueno, usemos una analogía. El dibujo arquitectónico se parece más al plano de construcción de las tuberías de agua y electricidad de la casa. Es muy técnico y le dice al ingeniero cómo encaminar las tuberías. El diagrama de casos de uso se parece más a un "diagrama de líneas de vida" para el propietario: aquí se cocina, se descansa allá y la sala de estar se utiliza para recibir invitados. Describe el valor que el sistema debe proporcionar desde la perspectiva de las empresas y los usuarios. Si primero aclara "qué tipo de vida quiere vivir" y luego diseña "cómo colocar las tuberías", a menudo es menos probable que se cometan errores.

Elección de herramientas: no permita que las buenas ideas queden atrapadas en software complejo

La idea es buena, pero cuando se trata de implementarla, la elección de las herramientas suele convertirse en el primer obstáculo. Lo que necesita es algo que le permita concentrarse en la "expresión" en sí, en lugar de luchar con operaciones engorrosas.

Debería ser lo suficientemente intuitivo. Puede arrastrar y soltar para conectar roles, casos de uso y relaciones, con tanta naturalidad como los bloques de construcción. También requiere un poco de seriedad y la capacidad de seguir algunas especificaciones básicas de UML para garantizar que lo que se dibuja pueda ser reconocido y comprendido por todos, en lugar de simples graffitis al azar. La flexibilidad también es clave: la relación entre microservicios a veces es bastante compleja. Un caso de uso puede involucrar múltiples servicios y un servicio puede admitir múltiples casos de uso. La herramienta debe poder expresar cómodamente esta relación de muchos a muchos, en lugar de obligarte a reducirla a una simple relación de uno a uno.

Más importante aún, los gráficos que genera deben estar "en vivo". A medida que sus microservicios se iteran y se agregan nuevas funciones, este diagrama debe actualizarse fácilmente y permanecer claro y legible. Debe ser un documento vivo del proyecto, no un recuerdo que se guarda encerrado en un cajón después de pintar.

De la mesa de dibujo a la realidad: que cada servicio encuentre su lugar

Cuando realmente comencemos a usar este diagrama para ordenar el proyecto, se producirán algunos cambios interesantes.

Los costos de comunicación han disminuido visiblemente. Procesos que antes requerían largas reuniones y extensos documentos para explicarse ahora pueden explicarse con una sola imagen como punto de partida para la discusión. "Mire, el proceso de registro de clientes involucra estos tres servicios y su punto de interacción está aquí". Los ojos de todos tienen un enfoque común.

Los límites de las responsabilidades del servicio se vieron obligados a aclararse. En el proceso de dibujo, te preguntarás constantemente: "¿A qué servicio pertenece esta función?" Esto puede prevenir eficazmente la "zona gris" de funciones superpuestas o faltantes entre servicios. Al igual que dividir una habitación en áreas funcionales, no habrá lavadora en la sala de estar ni cama en la cocina.

Además, le ayuda a identificar dependencias y riesgos técnicos de antemano. Si el diagrama muestra que un caso de uso crítico depende en gran medida de un servicio que aún no es estable, la luz del riesgo se apagará antes de tiempo. Puede considerar la tolerancia a fallas y los planes de degradación con anticipación en lugar de esperar hasta que algo salga mal después de conectarse.

Por supuesto, dibujar no es un truco de magia que se hace una sola vez. Requiere que pintes con un verdadero conocimiento del negocio. El diagrama inicial que dibujes puede ser aproximado, pero a medida que avance el desarrollo, continuarás corrigiéndolo, haciéndolo cada vez más refinado y más cercano a la verdadera apariencia del sistema. El proceso en sí es un muy buen pulido de diseño.

Entonces, ¿qué sigue?

Tal vez podrías intentar revisar un proyecto en el que estás trabajando actualmente o a punto de comenzar. Al menos, tome una hoja de papel en blanco (o una herramienta con la que se sienta cómodo), comience con los dos o tres objetivos comerciales principales y pregúntese: "¿Quién quiere esto? ¿Qué servicios tenemos para lograrlo? ¿Cómo encajan?".

Puede que al principio te resulte un poco desconocido, como dibujar un mapa por primera vez. Pero a medida que dibuja, puede descubrir algunos puntos de acoplamiento de servicios que no había notado antes, o descubrir que un determinado servicio asume demasiadas responsabilidades que deberían distribuirse. Este diagrama eventualmente se convertirá en un lenguaje común para el equipo, permitiendo que las discusiones sobre el comportamiento del sistema se lleven a cabo en un canal claro desde el principio.

Las buenas herramientas de diseño son como darle a tus pensamientos un lienzo claro. No piensa por usted, pero hace que los resultados del pensamiento sean visibles, discutibles e iterables. En un mundo lleno de interacciones dinámicas como los microservicios, un "mapa social" de este tipo puede ser el paso clave para que todo comience de manera ordenada.

Establecido en 2005,kpotenciase ha dedicado a un fabricante profesional de unidades de movimiento compacto, con sede en Dongguan, provincia de Guangdong, China. Aprovechando las innovaciones en la tecnología de accionamiento modular,kpotenciaintegra motores de alto rendimiento, reductores de precisión y sistemas de control multiprotocolo para proporcionar soluciones de sistemas de accionamiento inteligentes eficientes y personalizadas.kpotenciaha entregado soluciones de sistemas de accionamiento profesionales a más de 500 clientes empresariales en todo el mundo con productos que cubren diversos campos, como sistemas domésticos inteligentes, electrónica automática, robótica, agricultura de precisión, drones y automatización industrial.