Diagramando mensagens em um barramento de serviço

Estou procurando uma maneira de diagramar claramente como vários aplicativos se comunicam por meio de um barramento de serviço. O melhor que eu criei até agora é um diagrama de sequência, mas eu realmente não gosto disso. Os diagramas de sequência necessariamente relacionam algum tipo de sequência, e isso não é realmente o que eu quero. Além disso, como todo serviço se comunica com o barramento de serviço e os diagramas de sequência colocam cada serviço em uma coluna separada, à medida que o número de serviços aumenta, você acaba com muitas setas sobrepostas.

Por exemplo, dadas 4 serviços FOO, BAR, BAZ, e QUX:

FOOpublica mensagens do tipo publicar e regenerar .
BARpublica mensagens do tipo re-fila .
BAZassina mensagens do tipo publicar , regenerar e re - enfileirar e publica mensagens do tipo transmitir .
QUXassina mensagens do tipo transmitir .
Qualquer serviço pode publicar qualquer tipo de mensagem a qualquer momento (não há sequência implícita).

Que tipo de diagrama devo usar para representar clara e inequivocamente essas informações?

Aqui está o melhor que eu criei até agora:
Diagrama de sequência

diagrams pubsub service-bus

— pswg
fonte

Estou procurando uma maneira de diagramar claramente como vários aplicativos se comunicam por meio de um barramento de serviço.

Isso seria demais. Infelizmente, acho que não é possível configurações de qualquer complexidade. Um diagrama de sequência para cenários simples é provavelmente tão bom quanto qualquer outra coisa.

Os componentes em um barramento publicam e assinam mensagens. Algumas das mensagens podem estar causalmente relacionadas, formando um protocolo. É difícil mostrar isso graficamente, especialmente as relações causais, quando há mais de um protocolo em jogo no barramento.

Os diagramas de barramento elétrico existem há muito tempo

diagrama de barramento elétrico

mas eles lidam com uma quantidade de uma mercadoria uniforme (energia elétrica) e não com sinais discretos.

Gosto de mostrar as mensagens enviadas (à direita) e recebidas (à esquerda) por cada componente (e a estrutura do sub-canal / tópico, se aplicável), mas novamente para qualquer coisa, menos para os cenários mais simples, que os diagramas rapidamente se tornam confusos e quase inúteis .

insira a descrição da imagem aqui

Então, voltemos a uma pergunta mais fundamental: qual é o objetivo do diagrama? O que você está tentando mostrar?

Se você estiver tentando mostrar relações causais entre componentes e mensagens, faça um diagrama de um protocolo por vez usando um diagrama de sequência (ou equivalente).

Se você deseja apenas mostrar os protocolos para referência, colocar as mensagens enviadas e recebidas por cada componente deve ser documentação suficiente, mas os relacionamentos causais / temporais são perdidos.

Boa sorte e informe-nos se encontrar ou inventar algo melhor!

— Steven A. Lowe
fonte

Obrigado por tomar o tempo para responder. Para orquestrações complexas de mensagens ('conversas' dentro de 'protocolos'), sim, os diagramas seqüenciais são adequados. Mas, no momento, estou tentando abordar uma visão geral de alto nível de quais serviços são responsáveis por publicar um determinado tipo de mensagem e quais serviços podem ser afetados por um determinado tipo de mensagem, e não realmente a sequência de mensagens envolvidas. Espero algo padronizado, mas se eu acabar inventando o meu, provavelmente seria parecido com o diagrama de barramento elétrico que você deu como exemplo.

— precisa saber é

@pswg: de nada. Adicionado diagrama de exemplo, criado usando os Balsamiq Mockups. Eu uso pequenos círculos para fazer os pontos de conexão destacam-se, no caso de eu precisar de gateways anotar ou outras restrições

— Steven A. Lowe

Sim, algo assim iria funcionar. Acho que prefiro as pequenas flechas no diagrama elétrico a ter uma distinção esquerda / direita, mas isso me dá algumas idéias.

— PSWG

@pswg: achei as pequenas flechas no caminho para diagramas maiores;) Os componentes elétricos raramente (que eu vi) consomem e produzem energia, portanto as flechas são estáticas. Por isso fui com a distinção esquerda / direita (arbitrariamente). Também tento colocar as mensagens recebidas mais próximas da caixa do componente e as mensagens enviadas mais próximas da linha de ônibus - mas definitivamente não é a solução ideal. Ansioso para ver o que você vem com!

— Steven A. Lowe