diagrama de caso de uso para microsserviços

O que você deve fazer quando seus microsserviços começarem a “falar suas próprias palavras”?

Imagine: você tem um projeto muito complexo em mãos, arquitetura de microsserviços, parece muito sofisticado, certo? Cada serviço é bastante capaz, mas juntos? A comunicação é como uma conferência internacional sem intérprete. O serviço B não conseguiu compreender os dados gerados pelo serviço A; o serviço C enviou um comando, mas o serviço D ficou muito tempo sem responder. Com o passar do tempo, você descobrirá que poderá gastar mais tempo depurando e fazendo com que esses serviços "se entendam" do que desenvolvendo a funcionalidade em si.

Essa dúvida é bastante comum, certo? Muitas vezes nos concentramos em tornar cada serviço perfeito, mas esquecemos de criar um conjunto claro de “regras sociais” para eles. O resultado é confusão interna, ineficiência e até mesmo impedimento mútuo.

Existe um “mapa” que possa traçar claramente desde o início como estes serviços interagem e a quem servem? Torná-lo não apenas um diagrama técnico para desenvolvedores, mas também um “storyboard” que toda a equipe – até mesmo amigos que não têm tanto conhecimento técnico – possa entender?

Uma imagem pode fazer com que a colaboração deixe de ser “adivinhação”?

É aqui que entra o diagrama de casos de uso para microsserviços. Ele não se importa com o que é usado no seu código, ele se preocupa com “quem” (usuário ou sistema externo) quer “fazer” (objetivo) e “como” seu microsserviço responde a essas coisas.

Por exemplo, um cenário simples de comércio eletrônico. O usuário deseja concluir o pagamento. Esta imagem mostrará claramente que a função de “usuário” aciona o caso de uso de “pagamento”. Este caso de uso pode estar relacionado à colaboração entre “serviço de pedidos”, “serviço de pagamento” e “serviço de estoque”. Num relance, você sabe quais serviços devem ser envolvidos e quais são seus limites, em vez de esperar até que algo dê errado para descobrir de quem é a responsabilidade.

Alguém pode perguntar: “Qual é a diferença entre este e o diagrama de arquitetura do sistema que desenhamos antes?” Bem, vamos usar uma analogia. O desenho arquitetônico é mais parecido com o desenho da construção das tubulações de água e eletricidade da casa. É muito técnico e informa ao engenheiro como encaminhar os dutos. O Diagrama de Caso de Uso é mais como um “diagrama de linha de vida” para o proprietário: cozinha aqui, descansa ali e a sala é usada para receber convidados. Descreve o valor que o sistema deve fornecer da perspectiva dos negócios e dos usuários. Se você primeiro esclarecer “que tipo de vida você quer viver” e depois projetar “como instalar os canos”, será menos provável que cometa erros.

Escolhendo ferramentas: não deixe que boas ideias fiquem presas em softwares complexos

A ideia é boa, mas quando se trata de implementação, a escolha das ferramentas muitas vezes se torna o primeiro obstáculo. O que você precisa é de algo que permita que você se concentre na “expressão” em si, em vez de lutar com operações complicadas.

Deve ser bastante intuitivo. Você pode arrastar e soltar para conectar funções, casos de uso e relacionamentos, tão naturalmente quanto blocos de construção. Também requer um pouco de seriedade e a capacidade de seguir algumas especificações básicas da UML para garantir que o que é desenhado possa ser reconhecido e compreendido por todos, em vez de apenas grafites aleatórios. A flexibilidade também é fundamental – a relação entre microsserviços às vezes é bastante complexa. Um caso de uso pode envolver vários serviços e um serviço pode suportar vários casos de uso. A ferramenta deve ser capaz de expressar confortavelmente esse relacionamento muitos-para-muitos, em vez de forçá-lo a reduzi-lo a um simples relacionamento um-para-um.

Mais importante ainda, os gráficos que ele gera devem estar “ao vivo”. À medida que seus microsserviços são iterados e novos recursos são adicionados, esse diagrama deve ser facilmente atualizado e permanecer claro e legível. Deve ser um documento vivo do projeto, não uma lembrança que fica trancada em uma gaveta após a pintura.

Da prancheta à realidade: deixe cada serviço encontrar o seu lugar

Quando realmente começarmos a usar este diagrama para resolver o projeto, algumas mudanças interessantes acontecerão.

Os custos de comunicação caíram visivelmente. Processos que costumavam exigir longas reuniões e longos documentos para serem explicados agora podem ser explicados com uma única imagem como ponto de partida para discussão. “Olha, o processo de cadastro do cliente envolve esses três serviços, e o ponto de interação deles é aqui.” Os olhos de todos têm um foco comum.

Os limites das responsabilidades de serviço foram forçados a ficar claros. No processo de desenho, você se perguntará constantemente: "A qual serviço pertence esta função?" Isto pode prevenir eficazmente a “área cinzenta” de funções sobrepostas ou ausentes entre serviços. Tal como dividir um quarto em áreas funcionais, não haverá máquina de lavar na sala e não haverá cama na cozinha.

Além disso, ajuda a identificar antecipadamente dependências e riscos técnicos. Se o diagrama mostrar que um caso de uso crítico depende muito de um serviço que ainda não está estável, a luz de risco apagará mais cedo. Você pode considerar a tolerância a falhas e os planos de downgrade com antecedência, em vez de esperar até que algo dê errado depois de ficar online.

É claro que desenhar não é um truque de mágica feito de uma só vez. Exige que você pinte com uma verdadeira compreensão do negócio. O diagrama inicial que você desenha pode ser grosseiro, mas à medida que o desenvolvimento avança, você continuará voltando e corrigindo-o, tornando-o cada vez mais refinado e mais próximo da verdadeira aparência do sistema. O processo em si é um polimento de design muito bom.

Então, o que vem a seguir?

Talvez você possa tentar revisar um projeto em que está trabalhando ou prestes a iniciar. No mínimo, pegue um pedaço de papel em branco (ou uma ferramenta com a qual você se sinta confortável), comece com os dois ou três objetivos principais do negócio e pergunte-se: "Quem quer isso? Que serviços temos para alcançá-lo? Como eles se encaixam?"

Pode parecer um pouco estranho no início, como desenhar um mapa pela primeira vez. Mas à medida que você desenha, você pode descobrir alguns pontos de acoplamento de serviços que não percebeu antes, ou descobrir que um determinado serviço assume muitas responsabilidades que deveriam ser dispersas. Este diagrama eventualmente se tornará uma linguagem comum para a equipe, permitindo que discussões sobre o comportamento do sistema ocorram em um canal claro desde o início.

Boas ferramentas de design são como dar uma tela clara aos seus pensamentos. Ele não pensa por você, mas torna os resultados do pensamento visíveis, discutíveis e iteráveis. Num mundo cheio de interações dinâmicas como os microsserviços, esse “mapa social” pode ser o passo fundamental para que tudo comece de maneira ordenada.

Fundada em 2005,potênciatem se dedicado a um fabricante profissional de unidades de movimento compacto, com sede em Dongguan, província de Guangdong, China. Aproveitando inovações em tecnologia de acionamento modular,potênciaintegra motores de alto desempenho, redutores de precisão e sistemas de controle multiprotocolo para fornecer soluções de sistemas de acionamento inteligentes eficientes e personalizadas.potênciaforneceu soluções profissionais de sistemas de acionamento para mais de 500 clientes empresariais em todo o mundo, com produtos que abrangem vários campos, como sistemas domésticos inteligentes, eletrônica automática, robótica, agricultura de precisão, drones e automação industrial.